Received: from antares.mcs.anl.gov (mcs.anl.gov [140.221.9.6])
	by hub.org (8.9.3/8.9.3) with SMTP id VAA27386
	for <pgsql-interfaces@postgreSQL.org>;
	Mon, 21 Jun 1999 21:43:47 -0400 (EDT)
	(envelope-from selkovjr@xnet.com)
Received: from xnet.com (selkovjr@selkovjr.xnet.com [205.243.141.67]) by
	antares.mcs.anl.gov (8.6.10/8.6.10) with ESMTP
	id UAA24345 for <pgsql-interfaces@postgreSQL.org>;
	Mon, 21 Jun 1999 20:43:43 -0500
Message-Id: <199906220143.UAA24345@antares.mcs.anl.gov>
To: pgsql-interfaces@postgreSQL.org
From: selkovjr@mcs.anl.gov
Subject: Re: [INTERFACES] esql\c documentation 
In-Reply-To: Your message of "Mon, 21 Jun 1999 15:56:07 PDT."
	<XFMail.990621155607.orsingerc@epg-gw1.lewis.army.mil>
Date: Mon, 21 Jun 1999 20:46:39 -0400
Sender: selkovjr@xnet.com

> On 18-Jun-99 Michael Meskes wrote:
> >>         It doesn't work (in 6.4.2 and earlier, at least) without that 'IN'.
> >> In checking through the test source in the 6.5 version (directory 
> >> <source root>/src/interfaces/ecpg/test), I notice that the
> >> 'IN' is still included in all the FETCH statements. I don't know why I
> > 
> > The standard wants to see IN. Simply omitting it wouldn't even work with our
> > parser. It creates a shift/reduce conflict. Of course we could fix that but
> > I doubt adding a non-standard feature is worth that effort.

Excuse me -- what's wrong with shift/reduce conflicts? I have over a
hundred of those in one of my applications.

--Gene