Re: Fix for FETCH FIRST syntax problems
От | Tom Lane |
---|---|
Тема | Re: Fix for FETCH FIRST syntax problems |
Дата | |
Msg-id | 25267.1526773270@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Fix for FETCH FIRST syntax problems (Vik Fearing <vik.fearing@2ndquadrant.com>) |
Ответы |
Re: Fix for FETCH FIRST syntax problems
Re: Fix for FETCH FIRST syntax problems Re: Fix for FETCH FIRST syntax problems Re: Fix for FETCH FIRST syntax problems |
Список | pgsql-hackers |
Vik Fearing <vik.fearing@2ndquadrant.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
В списке pgsql-hackers по дате отправления: