From: | Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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-20 11:07:04 |
Message-ID: | f5cc6e99-cdf5-9fc6-ddbc-91b916877d33@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 20/05/18 01:41, Tom Lane wrote:
> Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com> writes:
>> On 20/05/18 00:57, Tom Lane wrote:
>> 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.
Only features we claim to support. I obviously wouldn't consider
backpatching ASSERTIONs, for example.
> 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?
Is the decision to backpatch based on behavior, or code churn?
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
From | Date | Subject | |
---|---|---|---|
Next Message | Vik Fearing | 2018-05-20 13:38:50 | Re: Fix for FETCH FIRST syntax problems |
Previous Message | Andrew Gierth | 2018-05-20 03:25:33 | Re: Fix for FETCH FIRST syntax problems |