----- Original Message -----
From: "Thomas Lockhart" <thomas@fourpalms.org>
To: "Michael Meskes" <meskes@postgresql.org>
Cc: "Nicolas Bazin" <nbazin@ingenico.com.au>;
<pgsql-interfaces@postgresql.org>
Sent: Saturday, March 16, 2002 4:11 AM
Subject: Re: [INTERFACES] ecpg weird behavior
> ...
> > > EXEC SQL FETCH curs_currency;
> > Anyone out there with more knowledge about standards? I thought this was
> > not standard at all.
>
> From what I can tell from my SQL99 maybe-docs we have all shared in the
> past on this list, the INTO is required to travel with the FETCH
> statement:
>
> <dynamic fetch statement> ::=
> FETCH [ [ <fetch orientation> ] FROM ] <dynamic cursor
> name>
> <output using clause>
>
> <output using clause> ::=
> <into arguments>
> | <into descriptor>
>
> <into arguments> ::=
> INTO <into argument> [ { <comma> <into argument> }... ]
>
> <into argument> ::= <target specification>
>
> <into descriptor> ::=
> INTO [ SQL ] DESCRIPTOR <descriptor name>
>
> hth
>
> - Thomas
>
> btw, I was working for the first time with ecpg and was very impressed.
> A company porting from Oracle ran into very few issues. Their existing
> code *did* have an Oracle extension to use a cursor to select multiple
> rows into variables declared as arrays. Have you run into this syntax or
> thought about what it would take to implement it?
>
Yes I also have this issue. From what I read in the ecpg doc, indexed
variables are not supported by ecpg and trying to compile the code definitle
proved it is not supported. The way I work arround it is to declare a local
variable of the same type, copy the array element into this variable,
perform the FECTH or SELECT and then copy the variable back into the array
element. I guess the preprocessor could also generate the code.
Another issue I had that ecpg does not support prepared statements. But I
didn't have that many prepared statements so I just rewrote the code.
