On Dec 29, 2010, at 2:01 PM, Dimitri Fontaine wrote: > # lo > comment = 'managing Large Objects' > version = '9.1devel' > relocatable = true > upgrade_from_null = 'null => lo.upgrade.sql' > > Here, any property that begins with 'upgrade_from_' is considered as an > upgrade setup and the part after the prefix is not considered. The > value is meant to have two parts separated by '=>', first is either null > or a regexp matched against currently installed version number, second > part is the upgrade script name to use at ALTER EXTENSION ... UPGRADE.
I thought we were going to try to avoid having entries for upgrades in the control file. > We support 'null' version number to be able to "upgrade" from existing > code which is not organized as an extension yet. The aim is to be able > to: > > CREATE EMPTY EXTENSION lo; -- version is null here > ALTER EXTENSION lo UPGRADE; > > And run a script containing lines that will look like this: > > alter domain @extsch...@.lo set extension lo; > alter function @extsch...@.lo_oid(lo) set extension lo; > alter function @extsch...@.lo_manage() set extension lo; > > Note that we always need to support the placeholder here, because of > course following dependencies at this point isn't possible. I thought placeholders were going away, too. Did I lose track? > Well, the way I see things, it's already too late and there's nothing we > can easily do to prevent that. What I mean is that the user will > typically upgrade the OS-level package first, then apply the upgrade on > the database(s). > > $ apt-get install postgresql-9.1-prefix > $ psql -U postgres -c 'alter extension prefix upgrade' somedb > > At the time you tell PostgreSQL about the new extension, the shared > object file has been in place for some time already, and the upgrade SQL > script has not been ran yet. That sounds dangerous. > What I hope extension authors will do is document whether any upgrade > requires a restart or will otherwise be responsible for instability in > the server for backend started with the newer .so before the upgrade > script has been run. So that users/DBA will know whether the upgrade > calls for a maintenance window. But if a new connection comes in, the .so will be loaded into the new child, no? Very dangerous. > I could see us trying to shoehorn such information into the control file > too, but would ERRORing out on LOAD be any better than taking the > compatibility chance? Knowing that the compatibility in most cases > depends a lot on the actual call paths? The new .so should not be installed until the upgrade is been run. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
