Re: ALTER EXTENSION UPGRADE, v3
Dimitri Fontaine <dimitri@2ndquadrant.fr>
From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "David E. Wheeler" <david@kineticode.com>, Florian Pflug <fgp@phlo.org>, Dimitri Fontaine <dimitri@2ndQuadrant.fr>, "Ross J. Reedstrom" <reedstrm@rice.edu>, Anssi Kääriäinen <anssi.kaariainen@thl.fi>, Itagaki Takahiro <itagaki.takahiro@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2011-02-03T18:27:01Z
Lists: pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes: > Now having said that, it does occur to me that there is an upgrade-ish > scenario that every user is going to hit immediately, which is how to > get from an existing installation with a pile of "loose" objects created > by one or more contrib modules to a state where those objects are > understood to be parts of modules. But that is a special case that > perhaps deserves a special-case solution, rather than inventing a very > large wheel. Well a good deal of the code I've written in the UGPRADE patch is there for this special case, that's ALTER OBJECT ... SET EXTENSION ...; This allows to "attach" any existing object to a given existing extension. Now what you need is a way to create an empty extension so that you can attach objects to it. That's in the patch in the form of the new command CREATE WRAPPER EXTENSION ...; WRAPPER was the most convenient keyword we already have I found. Then, there's only 2 things left in the patch. The contrib scripts that make that happen, and the control file support so that the command ALTER EXTENSION $contrib UPGRADE will run the upgrade script. This mechanism has been made in a way that allows it to cover running other scripts for other kind of upgrades. That's about it. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support