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