Received: from mout0.01019freenet.de (mout0.01019freenet.de [62.104.201.5])
	by hub.org (8.9.3/8.9.3) with ESMTP id HAA39760
	for <pgsql-interfaces@postgresql.org>;
	Fri, 18 Jun 1999 07:38:57 -0400 (EDT)
	(envelope-from Michael.Meskes@gmx.net)
Received: from [194.97.109.112] (helo=mx0.01019freenet.de)
	by mout0.01019freenet.de with esmtp (Exim 3.02 #5)
	id 10uwyy-000275-00
	for pgsql-interfaces@postgresql.org; Fri, 18 Jun 1999 13:38:52 +0200
Received: from [212.81.157.190] (helo=tanja.fam-meskes.de)
	by mx0.01019freenet.de with esmtp (Exim 3.02 #5) id 10uwya-0002M4-00
	for pgsql-interfaces@postgreSQL.org; Fri, 18 Jun 1999 13:38:29 +0200
Received: (from meskes@localhost)
	by tanja.fam-meskes.de (8.9.3/8.9.0/Debian/GNU) id NAA00453
	for pgsql-interfaces@postgreSQL.org; Fri, 18 Jun 1999 13:30:23 +0200
Date: Fri, 18 Jun 1999 13:30:23 +0200
From: Michael Meskes <meskes@postgresql.org>
To: pgsql-interfaces@postgresql.org
Subject: Re: [INTERFACES] esql\c documentation
Message-ID: <19990618133023.D382@gmx.net>
Mail-Followup-To: pgsql-interfaces@postgreSQL.org
References: <19990617104041.A2131@gmx.net>
	<XFMail.990617115814.orsingerc@epg-gw1.lewis.army.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.6i
In-Reply-To: <XFMail.990617115814.orsingerc@epg-gw1.lewis.army.mil>;
	from Craig Orsinger on Thu, Jun 17, 1999 at 11:58:14AM -0700

On Thu, Jun 17, 1999 at 11:58:14AM -0700, Craig Orsinger wrote:
> EXEC SQL DECLARE CURSOR <cursor id> FOR <select statement> ;
> EXEC SQL FETCH <cursor id> INTO <variable(s)> ;

Same with ORACLE.

>         Here's how ECPG does the same thing:
> 
> EXEC SQL DECLARE CURSOR <cursor id> FOR <select statemtent> ;
> EXEC SQL FETCH IN <cursor id> INTO <variable(s)> ;

That's what SQL-92 wants.

>         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.

>         So it would appear that PostgreSQL allows a FETCH command without
> a cursor, and the "IN" clause identifies a string as a cursor id ???
> This is substantially different from the way cursors and fetches are
> done in ESQL/C. For one thing, I can't find any way of doing more 
> than one row at a time (assuming that's what the "[number|ALL]" clause
> is about).

The FETCH command is completely handled by the backend. Everything that
works via psql should work via ecpg.

>         Hmmm. I don't explicitely enable transactions, but the only
> way that something seems to get done is by having that COMMIT statement
> at the end of the function. Do I have to turn off transaction processing
> explicitely?

Try ecpg -t. Without the '-t' ecpg automatically starts a transaction via
issuing the BEGIN command.

Michael
-- 
Michael Meskes                         | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz    | Go Rhein Fire!
Tel.: (+49) 2431/72651                 | Use Debian GNU/Linux!
Email: Michael.Meskes@gmx.net          | Use PostgreSQL!