On Dec 29, 2010, at 1:27 PM, Robert Haas wrote: > 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.
3. Check dependencies for one extension on other extensions. > 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. Yeah, makes sense. 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