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