Re: [INTERFACES] esql\c documentation

On 14-Jun-99 Michael Meskes wrote:
> On Sun, Jun 13, 1999 at 07:24:52PM -0500, Brent Waldrop wrote:
>> Does anyone know where this is thorough esql\c documentation. I am trying to
>
> Unfortunately there is no more than the man page and the sgml file
> distributed with PostgreSQL. I just didn't find the time to write more.
>
>> compile previous examples i used with informix and they will not work for
>> example when i do
>> EXEC SQL declare democursor cursor for
>> select fname,lname
>> into :fname, :lname
>> from employee
>> where lname < :oneline;
>> ---it bombs at the line with "into" in it saying there is a parse error
>> and when i do this EXEC SQL fetch democursor;
>> --it tells me that there is another parse error on this line
>> is there any better documenation for esql/c than whats available in the
>> programming manual so that i can figure out what is going on?
>
> To the best of my knowledge this is incorrect syntax. For instance Oracle
> says:
>
> The SELECT statement associated with the cursor cannot include an INTO
> clause. Rather, the INTO clause and list of output host variables are
> part of the FETCH statement.
>
> I cannot find the text in the standard right now, but there also only FETCH
> is listed with INTO.
>
> Please correct me if I'm wrong.

I don't know if this makes you wrong, but Informix supports
an INTO clause in a cursor declaration. It's one of the things I had to
change while porting some applications from Informix ESQL/C to ECPG.
Here's what Informix says about the INTO clause in their training
materials for ESQL/C:

You can use an INTO clause in the SELECT or use it in the
FETCH; you must use it in one or the other.

Right or wrong, it's definitely a part of their syntax. What's more,
their parser does not flag this clause as being not compliant with ANSI
SQL, as some of their other improvisations are.

This isn't a criticism BTW, just an observation. There are
enough other differences between these two embedded SQL implementations
that anyone who supports both will have to keep separate source files
anyway (at least for anything that's not a trivial application). So
much for standards.

----------------------------------
Date: 15-Jun-99 Time: 10:45:53

Craig Orsinger (email: <orsingerc(at)epg(dot)lewis(dot)army(dot)mil>)
Logicon RDA
Bldg. 8B28 "Just another megalomaniac with ideas above his
6th & F Streets station. The Universe is full of them."
Ft. Lewis, WA 98433 - The Doctor
----------------------------------