Dimitri Fontaine <dimi...@2ndquadrant.fr> writes:
> Tom Lane <t...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
