Re: Inline Extension - Mailing list pgsql-hackers

Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jan 23, 2012 at 7:59 PM, Daniel Farina <daniel@heroku.com> wrote:
>> Things are still a bit ugly in the more complex cases: consider
>> PostGIS's linkage against libproj and other libraries.  In order to

After thinking about that for a while I think we should not include the
shared module (.so) in the scope of this patch nor 9.2.  Ensuring that
the .so dependencies are met is a problem well outside the reach of the
PostgreSQL system.

>> cover all cases, I feel that what I need is an optional hook (for the
>> same of argument, let's say it's another "command" type hook, e.g.
>> "archive_command") to be executed when extension (un)installation is
>> occurs on a primary or is replayed on a standby whereby I can acquire
>> the necessary dependencies for an extension or signal some kind of
>> error (as to exactly how that interfaces with the server is delicate,
>> should one want to supply good error messages to the user).

Supporting command triggers on the replica is in the TODO list. Having
that in 9.2 is far from granted though, but the catalog and syntax
already have support for the feature.

> But, that's a bit unlike how we normally do things.  And if we're
> going to WAL-log the writing of the extension files, then I start to
> feel like we should go back to putting the data in a system catalog
> rather than the filesystem, because inventing a new WAL record type
> for this seems like it will make things quite a bit more complicated
> for no particular benefit.

Exactly, and we should talk about concurrent accesses to the filesystem
too, and how to have a clean transactional backup including the scripts
when that pg_dump option is used.

So I'm going to prepare the next version of the patch with this design:
- in catalog extension scripts for inline extension
  pg_extension_script(extoid, oldversion, version, script)
  oldversion is null when create extension is used  unless when using the create extension from 'unpackaged' form
- see about adding more control properties in the catalog?
- current code that is parsing the filenames to determine the upgrade  path will have to be able to take the version
stringsfrom the new  catalog as an alternative, and getting to the script content must be  able to select from the
catalogor read a file on disk 
- pg_dump defaults to not dumping extension content
- pg_dump --include-extension-scripts dumps the scripts found either in  the filesystem or the catalog, a create script
firstthen any number  of update script as needed to reach the current installed version 
- same as we have -t, add -e --extension to pg_dump so that you can  choose to dump only a given extension

The extension dumping will not include the shared modules, so if you
extension depend on them being installed on the server, you will be much
better served with some OS level packaging.

Not for 9.2, but I can't help thinking that if we could manage to host
the .so module itself in the catalogs, we could solve updating it in a
transactional way and more importantly host it per-database, rather than
having the modules work per major version (not even per cluster) and the
extension mechanism work per-database inside each cluster. But that's
work for another release.

Any comments before I spend time coding this?
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support