Re: Split-up ECPG patches - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Split-up ECPG patches
Date
Msg-id 29782.1249766946@sss.pgh.pa.us
Whole thread Raw
In response to Re: Split-up ECPG patches  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Split-up ECPG patches  (Boszormenyi Zoltan <zb@cybertec.at>)
Re: Split-up ECPG patches  (Michael Meskes <meskes@postgresql.org>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Split-up ECPG patches
Next
From: Mark Kirkwood
Date:
Subject: Re: Lock Wait Statistics (next commitfest)