Re: [INTERFACES] esql\c documentation - Mailing list pgsql-interfaces

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@epg.lewis.army.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
----------------------------------