Hi,

Bruce Momjian wrote:
So, ideally, if we do a plug-in system, I think we need some way to have
these plugins be very easily installed, perhaps by choosing object files
pre-compile by the build farm for each operating system.

IIRC the main problem isn't compilation and packaging of plugins. On your Ubuntu system, for example, you can easily install 'postgresql-contrib-8.x' and get most of the contrib modules as *.so libraries. You'll even find the install_*.sql and uninstall_*.sql scripts in '/usr/share/postgresql/8.x/contrib'.

The main problem I see is ease of installation and backup/restore capability of these modules. Installing the tsearch2 module with:

  psql $YOURDB < /usr/share/postgresql/8.x/contrib/tsearch2.sql

..is already quite easy to do. But beware of the trouble when trying to back up and restore that database later on!


At the moment, we distinguish between system objects, initdb objects and user objects by OID:

#define FirstBootstrapObjectId  10000
#define FirstNormalObjectId     16384


But objects created by modules are indistinguishable from user objects. IMO, that's the main problem. Maybe we can solve this by reserving yet another range of OIDs for modules. Then treat these objects as 'system' objects during a pg_dump? I'm not sure if such a limited range of OIDs is a good idea, but IMO the ability to tell apart system, module and user objects is the key feature required here.

Regards

Markus Wanner


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to