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