Re: proposal: ANSI SQL 2011 syntax for named parameters

On Wed, Feb 6, 2013 at 1:06 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 6 February 2013 17:43, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Mon, Feb 4, 2013 at 3:32 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>> On 4 February 2013 19:53, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>> This seems pretty close to an accusation of bad faith, which I don't
>>>> believe to be present.
>>>
>>> Robert, this is not an accusation of bad faith, just an observation
>>> that we can move forwards more quickly.
>>
>> It's your opinion, to which you are certainly entitled, but it is not
>> an observation of an objective fact.
>
> And what? You expressed an opinion, as did I.
>
> I repeat: I don't see why waiting a year changes anything here. Can
> you please explain why the situation is improved by waiting a year?

What was unclear or incomplete about the last two times I explained
it? Here's what I wrote the first time:

$ Keep in mind that, as recently as PostgreSQL 9.1, we shipped hstore
$ with a =>(text, text) operator. That operator was deprecated in 9.0,
$ but it wasn't actually removed until PostgreSQL 9.2. Whenever we do
$ this, it's going to break things for anyone who hasn't yet upgraded
$ from hstore v1.0 to hstore v1.1. So I would prefer to wait one more
$ release. That way, anyone who does an upgrade, say, every other major
$ release cycle should have a reasonably clean upgrade path.

And here's what I wrote the second time:

$ 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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company