| 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: | Whole Thread | Raw Message | 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?
| 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 |