Re: ecpg weird behavior

From: Thomas Lockhart <thomas(at)fourpalms(dot)org>
To: Michael Meskes <meskes(at)postgresql(dot)org>
Cc: Nicolas Bazin <nbazin(at)ingenico(dot)com(dot)au>, pgsql-interfaces(at)postgresql(dot)org
Subject: Re: ecpg weird behavior
Date: 2002-03-15 17:11:34
Message-ID: 3C922B46.BA9F85D@fourpalms.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

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

In response to

Responses

Browse pgsql-interfaces by date

  From Date Subject
Next Message Jeroen T. Vermeulen 2002-03-17 00:27:27 libpqxx milestone
Previous Message Arguile 2002-03-15 15:13:41 Re: perl dbi postgresql uppercase problem