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.
Best,
David