Re: Fix for FETCH FIRST syntax problems

Поиск
Список
Период
Сортировка
От Vik Fearing
Тема Re: Fix for FETCH FIRST syntax problems
Дата
Msg-id 03da97fc-9d6b-cbe1-c28f-cee7c1ba5c38@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: Fix for FETCH FIRST syntax problems  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Fix for FETCH FIRST syntax problems  (Vik Fearing <vik.fearing@2ndquadrant.com>)
Re: Fix for FETCH FIRST syntax problems  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 20/05/18 00:57, Tom Lane wrote:
> Andrew Gierth <andrew@tao11.riddles.org.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Fix for FETCH FIRST syntax problems
Следующее
От: Vik Fearing
Дата:
Сообщение: Re: Fix for FETCH FIRST syntax problems