Re: Extensions, patch v16

On Wed, Dec 29, 2010 at 3:23 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Bruce Momjian <bruce(at)momjian(dot)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