Re: [HACKERS] Data type removal
От | darrenk@insightdist.com (Darren King) |
---|---|
Тема | Re: [HACKERS] Data type removal |
Дата | |
Msg-id | 9803241611.AA28930@ceodev обсуждение исходный текст |
Ответы |
Re: [HACKERS] Data type removal
|
Список | pgsql-hackers |
> > 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
В списке pgsql-hackers по дате отправления: