Re: [INTERFACES] esql\c documentation

On 18-Jun-99 Michael Meskes wrote:
>> 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.

Well, it sounds like a pretty popular non-standard, since
both Informix and Oracle use it. Nevertheless, I'd have to agree
with you, if it's a lot of trouble. PostgreSQL cursors most closely
resemble what Informix calls "scroll cursors", with the added ability
to fetch more than one row at a time. In addition to using different
keywords for scrolling direction ("PREVIOUS/NEXT" vs.
"FORWARD/BACKWARD"), PostgreSQL does not support the ABSOLUTE, FIRST,
or LAST directions, and the RELATIVE clause does not have the same
syntax (see next paragraph for an explanation). For more high-perfor-
mance applications than mine, there is likely to be little resemblence
between the embedded SQL for these two databases. If the "IN" was made
optional, I could write DECLARE/OPEN/FETCH sequences that were
compatible, but I would not be making the best use of either DBMS.

Here's the difference in the RELATIVE clause:

FETCH RELATIVE 2 [IN] cursor ;

In Informix, this fetches the current row, then skips two
rows. In psql, this fetches the next two rows, then skips to the
first row after. I don't know what the SQL92 spec says, but to me,
the way Informix behaves makes more sense. After all, what good is
a RELATIVE clause if not to modify how many rows you skip? IOW,
there needs to be a numerical field after "RELATIVE" for it to do
any good. I'm referring to how psql 6.4.2 behaves, BTW.

Practically speaking, if there's no agreement among these
embedded SQL implementations as to how to do preprocessor directives
like "EXEC SQL IFDEF", then the only alternative if one wants to
maintain a single source file for each function is to use sed, yacc,
perl or some other macro language to generate the appropriate
embedded SQL source. Are things like IF, IFDEF, ELSE, etc., defined
in the SQL92 standard?

----------------------------------
Date: 21-Jun-99 Time: 10:09:24

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