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
> 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.
In response to
pgsql-hackers by date
|Next:||From: Dan Scales||Date: 2012-01-27 00:01:21|
|Subject: Re: 16-bit page checksums for 9.2|
|Previous:||From: Tom Lane||Date: 2012-01-26 23:03:41|
|Subject: Re: WIP patch for parameterized inner paths |