Thread

Re: [HACKERS] Data type removal

Darren King <darrenk@insightdist.com> — 1998-03-24T16:11:02Z

> >    How about this as a compromise.  We make these packages available in
> > the contrib or other such area as loadable modules as well as making
> > them available right in the main backend code, but setup configure
> > options to enable/disable them, so when I compile, I can say
> > "--without-geometry" to compile without those types and functions.  If I
> > want to add them back in later, I can compile the loadable module
> > version and add them in. 
> 
> 	As I stated earlier, if someone wants to add a
> '--without-geometry' option to configure that removes it, I have no problem
> with that...but it will only be to remove the feature, not add it in.

I can live with this.  Everything is "--with-xxx" by default, but can not
be built in by using "--without-xxx".

Would it be acceptable to move the code for these to a new directory, say,
src/modules?  Something along the lines of...

src/modules/geometric
src/modules/ip_and_mac

This would allow for each type to have a pg_proc.h, pg_type.h, etc.  Much
cleaner than #define'ing the heck out of the existing include files.  The
geometric/pg_proc.h would contain the entries from pg_proc.h.  Then there
would also be a .sql file that contains the necessary commands to load
the module if it was not compiled in or was just needed in one database.

Forcing someone to re-compile to use module would seem to go completely
against the extensibility side of postgres.

I think once there is one thing there as a module, it will serve as an
example for others.  A simple example would be the cash/money code. Add
an indexing method to it and it would be a brief but complete example.

darrenk