|From:||Markus Wanner <markus(at)bluegap(dot)ch>|
|To:||Bruce Momjian <bruce(at)momjian(dot)us>|
|Cc:||"Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org|
|Subject:||Re: Plugin system like Firefox|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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.
|Next Message||Markus Wanner||2008-08-12 08:14:32||Re: WIP: New Page API|
|Previous Message||Dave Page||2008-08-12 07:26:31||Re: Plugin system like Firefox|