Folks,
While doing some other cursor-related work, I noticed the following two
issues:
(1) Lack of NO SCROLL
The SQL spec specifies that you should be able to specify NO SCROLL to
DECLARE CURSOR to disallow bidirectional fetching on the cursor. We
currently support the SCROLL syntax, but it had no significant effect on
the behavior of the cursor. This was pretty easy to fix, so I
implemented NO SCROLL.
However, the SQL spec says that if neither SCROLL or NO SCROLL is
specified, NO SCROLL should be implicit (SQL 2003 draft, 14.1, Syntax
#7). This isn't how cursors have traditionally behaved in PostgreSQL --
backward and forward fetches have always been allowed, whether SCROLL
was specified or not.
Should we change this behavior to be spec compliant, or default to
SCROLL if neither is specified?
(2) Error handling
If a DECLARE CURSOR is executed for a cursor name that already exists,
the existing cursor is closed and replaced by the new cursor (a WARNING
is issued). Similarly, a FETCH executed on a non-existent cursor yields
a WARNING, not an ERROR.
These are not good responses, IMHO: they seem illogical, and they
conflict with the way that the vast majority of other commands behave.
Should we change this?
Cheers,
Neil
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
