On Fri, Dec 10, 2010 at 4:50 PM, Dimitri Fontaine <dimi...@2ndquadrant.fr> wrote:
> Now, what about having the control file host an 'upgrade' property where > to put the script name? We would have to support a way for this filename > to depend on the already installed version, I'm thinking that %v might > be the easiest here (read: I want to avoid depending on any version > scheme). > > version = '13' > script = 'foo.sql' > upgrade = 'foo_upgrade.%v.13.sql' If I was linking of putting bundling my "utiliites" up as an extension (yes, I would that from a packaging/DB management perspective), I think I'ld like a control like that, but with a bit of a "wildcard" version matching, something like: version = '3.12' upgrade-1. = 'utils-upgrade-1.0.sql' upgrade-2. = 'utils-upgrade-2..0.sql upgrade-3. = 'nothing' I'm thinking of a scheme where the upgrade-$VERSION uses a prefix match, so 1.1, 1.2, 1.3 would all be matched by "1.". The 3.=nothing is some way of specifing you don't need to do anything, becuase my n.X release are all compatible sql->so wise. They would only be "bug fixes" if I did something wrong in my stuff.. Anything not compatible woudl bump the first number. If it's a "prefix" type match, then the PG versionins woudl work too, for intsance: upgrade-9.0.=... would match any pg 9.0.* I guess you could use SQL like if that' more "consitent"... a. -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
