> > 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
