Re: ALTER EXTENSION UPGRADE, v3

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
Cc: Aidan Van Dyk <aidan@highrise.ca>, "David E. Wheeler" <david@kineticode.com>, Robert Haas <robertmhaas@gmail.com>, Josh Berkus <josh@agliodbs.com>, pgsql-hackers@postgresql.org
Date: 2011-02-11T20:38:28Z
Lists: pgsql-hackers
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> I don't see that this proposal changes anything about that.  It's still
>> the case that the underlying .so is tied to a major PG version.  What
>> you'll ship is a control file and assorted .sql files that represent the
>> user APIs you are interested in supporting on that major PG version.

> That's why I proposed that the require control field would contain the
> PostgreSQL release against which the extension is built.

>   require = 'postgresql-9.0'

I don't see what that does for you.  This is still all being examined by
a particular major release of PG, so what will it do with a require that
specifies some other major release?  Nothing useful.  And there's a very
significant downside, which is that this takes us right back to the
make-work of having to change all the contrib modules' control files in
every release cycle.

Once again, I see the version numbers as being specifiers for versions
of the install script files.  Not the Postgres version those files are
being run in.  Confusing the two is a bad idea.  Confusing the install
script version numbers with minor release numbers (bugfix level
identifiers) is even worse.  You *don't* want to change these numbers if
you're just fixing a bug at the C code level.

			regards, tom lane