On Sun, 29 Dec 2002 16:39:37 -0800, Kevin Brown <kevin@sysexperts.com>
wrote:
>> > Okay. But then doesn't it make sense for FETCH to fetch the contents
>> > of the row (and subsequent requested rows) that the cursor is
>> > currently on *then* move, and not the other way around?
>This model is extremely common and, IMO, sensible.
OTOH, seeing a row *before* updating or deleting it is *extremely*
useful. Here is what you are proposing:
SELECT * FROM t ORDER BY id;
id | txt
---+---------------1 | leave me alone2 | delete me3 | keep me
BEGIN;
DECLARE c CURSOR FOR SELECT * FROM t ORDER BY id;
FETCH 1 FROM c;
id | txt
---+---------------1 | leave me alone
-- ok, leave it alone ...
FETCH 1 FROM c;
id | txt
---+---------------2 | delete me
-- got it! (really??)
DELETE FROM t WHERE CURRENT OF c;
COMMIT;
SELECT * FROM t ORDER BY id;
id | txt
---+---------------1 | leave me alone2 | delete me
-- oops!!
> just as you'd expect
No, not me. Would *you* expect this? If you really want to draw an
analogy between databases and editors, compare rows to lines, not
characters. Now imagine an editor window just one line high, then it
is clear that after a row is brought into the window you don't want
the cursor to silently advance to the next (invisible) row.
ServusManfred