Re: Fix for FETCH FIRST syntax problems - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fix for FETCH FIRST syntax problems
Date
Msg-id 25267.1526773270@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fix for FETCH FIRST syntax problems  (Vik Fearing <vik.fearing@2ndquadrant.com>)
Responses Re: Fix for FETCH FIRST syntax problems  (Michael Paquier <michael@paquier.xyz>)
Re: Fix for FETCH FIRST syntax problems  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Re: Fix for FETCH FIRST syntax problems  (Vik Fearing <vik.fearing@2ndquadrant.com>)
Re: Fix for FETCH FIRST syntax problems  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
Vik Fearing <vik.fearing@2ndquadrant.com> writes:
> On 20/05/18 00:57, Tom Lane wrote:
>> Also, why'd you back off "must write" to "should write" in the docs?
>> This doesn't make the parens any more optional than before.

> It certainly does.  It allows this now:
> PREPARE foo AS TABLE bar FETCH FIRST $1 ROWS ONLY;

No, it makes the parens omittable in the cases specified in the previous
sentence.  The sentence I'm complaining about is describing other cases,
in which they're still required.

> I'm +1 for backpatching it.  It may be operating as designed by PeterE
> ten years ago, but it's not operating as designed by the SQL standard.

By that argument, *anyplace* where we're missing a SQL-spec feature
is a back-patchable bug.  I don't buy it.

It may be that this fix is simple and safe enough that the risk/reward
tradeoff favors back-patching, but I think you have to argue it as a
favorable tradeoff rather than just saying "this isn't per standard".
Consider: if Andrew had completely rewritten gram.y to get the same
visible effect, would you think that was back-patchable?

            regards, tom lane


pgsql-hackers by date:

Previous
From: Vik Fearing
Date:
Subject: Re: Fix for FETCH FIRST syntax problems
Next
From: Michael Paquier
Date:
Subject: Re: Fix for FETCH FIRST syntax problems