Re: Fix for FETCH FIRST syntax problems
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Vik Fearing <vik.fearing@2ndquadrant.com>, Andrew Gierth <andrew@tao11.riddles.org.uk>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2018-05-20T20:13:10Z
Lists: pgsql-hackers
On Sat, May 19, 2018 at 4:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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? I strongly agree with the general principle that back-patching a bug fix needs to have a benefit that outweighs its cost. There have been cases where we chose to not back-patch an unambiguous bug fix even though it was clear that incorrect user-visible behavior remained. Conversely, there have been cases where we back-patched a commit that was originally introduced as a performance feature. Whether or not Andrew's patch is formally classified as a bug fix is subjective. I'm inclined to accept it as a bug fix, but I also think that it shouldn't matter very much. The practical implication is that I don't think it's completely out of the question to back-patch, but AFAICT nobody else thinks it's out of the question anyway. Why bother debating something that's inconsequential? FWIW, I am neutral on the important question of whether or not this patch should actually be back-patched. -- Peter Geoghegan
Commits
-
Fix SQL:2008 FETCH FIRST syntax to allow parameters.
- 89b09db01b43 9.3.24 landed
- 769e6fcd1a35 9.4.19 landed
- 3b0fb2529fdf 9.5.14 landed
- 7a0aa8d12ace 9.6.10 landed
- cf516dc9d690 10.5 landed
- 1da162e1f5a7 11.0 landed
-
SQL:2008 alternative syntax for LIMIT/OFFSET:
- 361bfc35724a 8.4.0 cited