Re: MOVE strangeness

On Sun, 29 Dec 2002 16:39:37 -0800, Kevin Brown <kevin(at)sysexperts(dot)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 alone
2 | delete me
3 | 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 alone
2 | 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.

Servus
Manfred