On Sun, 29 Dec 2002 16:39:37 -0800, Kevin Brown <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
