On Wed, Dec 29, 2010 at 3:23 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Bruce Momjian <br...@momjian.us> writes: >> Oleg Bartunov wrote: >>> it's clear we need versions, probably, major.minor would be enough. The >>> problem >>> I see is how to keep .so in sync with .sql ? Should we store .sql in >>> database ? > >> Don't people normally define the version number in the Makefile and pass >> the version string into the C code and perhaps a psql variable? > > We had a long discussion upthread of what version numbers to keep where. > IMHO the Makefile is about the *least* useful place to put a version > number; the more so if you want more than one. What we seem to need is > a version number in the .sql file itself (so that we can tell whether we > need to take action to update the extension's catalog entries). I'm not > convinced yet whether there needs to be another version number embedded > in the .so file --- it may well be that the PG major version number > embedded with PG_MODULE_MAGIC is sufficient. > > Personally I'd forget the notion of major.minor numbers here; all that > will accomplish is to complicate storage and comparison of the numbers. > We just need a simple integer that gets bumped whenever the extension's > SQL script changes.
I think there are really two tasks here: 1. Identify whether a newer set of SQL definitions than the one installed is available. If so, the extension is a candidate for an upgrade. 2. Identify whether the installed version of the SQL definitions is compatible with the installed shared object. If it's not, we'd like the shared library load (or at a minimum, any use of the shared library) to fail when attempted, rather than attempting to plunge blindly onward and then crashing. As to point #2, what an extension author would typically do (I hope) is publish a new shared object is make it backward-compatible with some number of previous versions of the SQL definitions, but not necessarily all the way to the beginning of time. So the typical upgrade sequence would be to install the new .so, and then upgrade the SQL definitions. You'd want an interlock, though, in case someone tried to use a set of SQL definitions that were either too new or too old for the corresponding shared library. The "too new" case could occur if someone installed a new version of the shared library, upgraded the SQL definitions, and then put the old shared library file back. The "too old" case could occur if the extension were upgraded through many releases in a single step, such that whatever backward-compatibility support existed in the shared library didn't reach back far enough to cater to the ancient SQL definitions. In either case, you want to chunk an error when someone tries to use the module, rather than soldiering on blindly and crashing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
