Robert Haas <robertmhaas@gmail.com> writes:
> $ Right now there is one and only one release in
> $ the field that contains hstore 1.1. If we go ahead and prohibit => as
> $ an operator name now, we're going to require everyone who is on 9.1
> $ and uses hstore and wants to get to 9.3 to either (a) first upgrade to
> $ 9.2, then update hstore, then upgrade to 9.3; or (b) dig the
> $ hstore-1.1 update out of a future release, apply it to an earlier
> $ release on which it did not ship, and then upgrade.
>
> I don't know what to add to that.
There's no technical reason that I'm aware of for hstore 1.1 not to
support all our maintained releases at the same time. That's exactly how
we do it with non-core extensions, by the way.
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';
That support is going to ease a lot dump and support of Extensions
installed from a Template, too, so much so that I would really like to
get some reviewing about that before sending the full patch.
We've been talking about "in-core extensions" as opposed to contribs for
a while now, I think this is another angle to see things through. We
could actually maintain proper extensions the proper way.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
