Skip site navigation (1) Skip section navigation (2)

Re: Inline Extension

From: "David E(dot) Wheeler" <david(at)justatheory(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Daniel Farina <daniel(at)heroku(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Inline Extension
Date: 2012-01-26 23:48:12
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.



In response to


pgsql-hackers by date

Next:From: Dan ScalesDate: 2012-01-27 00:01:21
Subject: Re: 16-bit page checksums for 9.2
Previous:From: Tom LaneDate: 2012-01-26 23:03:41
Subject: Re: WIP patch for parameterized inner paths

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group