On Jan 26, 2012, at 9:40 AM, Dimitri Fontaine wrote:

> 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

Would you keep all the migration scripts used over time to upgrade from one 
version to another?

> - 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 strings from the new
>   catalog as an alternative, and getting to the script content must be
>   able to select from the catalog or 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 first then 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

Also --exclude-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.

Or must make sure it’s installed on the system before you restore.

> 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.

+1 Cloud vendors will *love* this.



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

Reply via email to