From: | Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Fix for FETCH FIRST syntax problems |
Date: | 2018-05-19 23:27:30 |
Message-ID: | 03da97fc-9d6b-cbe1-c28f-cee7c1ba5c38@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 20/05/18 00:57, Tom Lane wrote:
> Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
>> Attached is a draft patch for fixing that, which additionally fixes the
>> ugly wart that OFFSET <x> ROW/ROWS and FETCH FIRST [<x>] ROW/ROWS ONLY
>> had very different productions for <x>; both now accept c_expr there.
>
> LGTM, except please s/presense/presence/ in grammar comment.
> 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;
>> I think a case can be made that this should be backpatched; thoughts?
>
> Meh, -0.5. This is not really a bug, because it's operating as designed.
> You've found a reasonably painless way to improve the grammar, which is
> great, but it seems more like a feature addition than a bug fix.
>
> I'd be fine with sneaking this into v11, though.
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.
--
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-19 23:30:00 | Re: Fix for FETCH FIRST syntax problems |
Previous Message | Tom Lane | 2018-05-19 22:57:55 | Re: Fix for FETCH FIRST syntax problems |