Re: [INTERFACES] esql\c documentation

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!