Tom Lane <tgl@sss.pgh.pa.us> writes:
> If you're suggesting that we should back-patch hstore 1.1 into 9.1,
> there might not be a technical reason why we couldn't do it, but there
> are certainly project-policy reasons. Removing operators, or indeed
> changing any SQL interface at all, is exactly the kind of change we do
> not make in back branches.
For core itself, it makes perfect sense. For extensions, I wonder about
the upgrade path, and if we shouldn't leave some level fo choice to the
user. Shipping the ability to upgrade to hstore 1.1 into back branches
is not the same thing as upgrading our users.
>> To make that easier to maintain, there's a patch in the queue
>> implementing default_major_version so that we can ship hstore--1.0.sql
>> and hstore--1.0--1.1.sql and still have that command just works:
>> CREATE EXTENSION hstore VERSION '1.1';
>
> If the argument for this patch is only to support doing something like
> the above, I'd vote for rejecting it entirely.
This patch allows us to ship bug and security fixes in back branches
without having to maintain both the 1.1 and the 1.2 full scripts, as
PostgreSQL will now be able to install 1.1 and upgrade to 1.2 at CREATE
EXTENSION time.
So no, this patch is not made for something like forcing incompatible
changes down the throat of our users, it's made to make the life of
extension maintainers (core included) easier.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
