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
