From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Boszormenyi Zoltan <zb(at)cybertec(dot)at> |
Cc: | Michael Meskes <michael(at)fam-meskes(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, hs(at)cybertec(dot)at |
Subject: | Re: Split-up ECPG patches |
Date: | 2009-08-08 21:29:06 |
Message-ID: | 29782.1249766946@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Kirkwood | 2009-08-09 00:47:18 | Re: Lock Wait Statistics (next commitfest) |
Previous Message | Tom Lane | 2009-08-08 20:57:57 | Re: Split-up ECPG patches |