Re: Split-up ECPG patches
От | Tom Lane |
---|---|
Тема | Re: Split-up ECPG patches |
Дата | |
Msg-id | 29782.1249766946@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Split-up ECPG patches (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Split-up ECPG patches
Re: Split-up ECPG patches |
Список | pgsql-hackers |
I wrote: > The fundamental reason that there's a problem here is that ecpg has > decided to accept a syntax that the backend doesn't (ie, FETCH with a > fetch direction but no FROM/IN). I think that that's basically a bad > idea: it's not helpful to users to be inconsistent, and it requires ugly > hacks in ecpg, and now ugly hacks in the core grammar as well. We > should resolve it either by taking out that syntax from ecpg, or by > making the backend accept it too. Not by uglifying the grammars some > more in order to keep them inconsistent. On looking a bit closer at this: I think the reason the core grammar requires FROM/IN after fetch_direction is to leave the door open for someday generalizing the fetch count to be an expression, not just an integer constant. If we made FROM/IN optional, then doing that would require some ugly syntax hack or other, such as requiring parentheses around nontrivial expressions. So I'd like to see an actual case made that there's a strong reason for not requiring FROM/IN in ecpg. regards, tom lane
В списке pgsql-hackers по дате отправления: