| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com> |
| Cc: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Fix for FETCH FIRST syntax problems |
| Date: | 2018-05-19 23:41:10 |
| Message-ID: | 25267.1526773270@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2018-05-19 23:57:06 | Re: Fix for FETCH FIRST syntax problems |
| Previous Message | Vik Fearing | 2018-05-19 23:30:00 | Re: Fix for FETCH FIRST syntax problems |