Re: MOVE strangeness
От | Kevin Brown |
---|---|
Тема | Re: MOVE strangeness |
Дата | |
Msg-id | 20021227080436.GC17998@filer обсуждение исходный текст |
Ответ на | Re: MOVE strangeness (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: MOVE strangeness
|
Список | pgsql-hackers |
Tom Lane wrote: > The cursor must be considered to be positioned on its current row, not > between rows, or the SQL-defined operations UPDATE WHERE CURRENT OF and > DELETE WHERE CURRENT OF don't make any sense. (We don't support those > yet, but we should someday.) 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? Were that the model, then the only situation in which the cursor would not be on a row is if it's past the last one (or if it pointed to an empty set). And the initial declaration of the cursor would thus normally place the cursor on the first row fetched, just as you'd expect. "Fetch 3" would fetch whatever row the cursor is currently on and the following 2 rows, then move the cursor down 3 rows (so that it's on the row that follows the last row fetched). Additionally, with that model, UPDATE WHERE CURRENT OF would work exactly as you'd expect in all situations: it would update the row the cursor is on or, if the cursor is beyond the last row, would fail. MOVE would also work exactly as you'd expect: MOVE -3 would move the cursor back 3 positions, or to the beginning of the set, whichever comes first, and would report how many positions it was able to move. My read of the spec indicates that cursors don't behave the way I describe above. If I'm right, then does anyone here know why the spec calls for something different? -- Kevin Brown kevin@sysexperts.com
В списке pgsql-hackers по дате отправления: