Re: proposal: ANSI SQL 2011 syntax for named parameters - Mailing list pgsql-hackers

On 6 February 2013 20:31, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Feb 6, 2013 at 1:06 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> On 6 February 2013 17:43, Robert Haas <robertmhaas@gmail.com> wrote:
>>> On Mon, Feb 4, 2013 at 3:32 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>>> On 4 February 2013 19:53, Robert Haas <robertmhaas@gmail.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.

I don't see a problem with requiring that, but there are other ways also.

hstore, as well as other code, might contain a definition of the =>
operator. So the hstore situation isn't that relevant in itself.

There is potentially code out there that currently runs on PostgreSQL
that uses =>. There is also potentially code out there that could run
on Postgres if we allow the => standard syntax.  There is also a
conflict in that we are continuing to encourage the development of
non-standard code because we aren't supporting the standard yet. So
there is a conflict.

IMO the way to resolve that conflict is with a behaviour parameter to
allow people to choose, rather than be forced to wait a year because
some people still run an old version of an add-on package. A good way
to do that would be to have a sql_standard = postgres | 2011 etc so we
can tick the box in having a sql standard flagger as well.

I believe the same issue exists with the -> operator, which is also
part of the SQL standard on "reference types".

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services