Re: Message of MOVE
От | Hannu Krosing |
---|---|
Тема | Re: Message of MOVE |
Дата | |
Msg-id | 3A7DD5CD.8AF9062@tm.ee обсуждение исходный текст |
Ответ на | Message of MOVE (Kovacs Baldvin <kb136@hszk.bme.hu>) |
Список | pgsql-hackers |
Kovacs Baldvin wrote: > > Hi! > > I would like to ask you, the developers about the following > question. > > Because I wanted to know after issuing a MOVE, that how many > steps did really happen, I made a patch, and now the backend > not only replies "MOVE" but "MOVE XXX", where XXX is the > number of steps. It needed only a few new lines (3 or 4 :-) > > Now the question is: should I use this solution,or should > I use an other? Is it possible that others are also interested > about this? At least I would need it. I was myself contemplating adding a function that would tell me how many rows a select returned (without actually retrieving all of them) and this seems to cover it nicely so I could do: BEGIN; DECLARE mycursor SCROLL cursor for SELECT * from t; MOVE 2000000000 IN mycursor; <parse out the real move into X>; MOVE -(X+1) IN mycursor; <do what I need>; END; > Is it possible, that including this into the > source would be wrong, because some standards say "Say only > move, but don't tell how many rows you really moved?" I could not find _any_ MOVE command in ansi-iso-9075-2-1999.txt so even our MOVE syntax is probably non-standard: So seems to be our FETCH, as standard defines it as: <fetch statement> ::= FETCH [ [ <fetch orientation> ] FROM ] <cursor name> INTO <fetchtarget list> <fetch orientation> ::= NEXT | PRIOR | FIRST | LAST | { ABSOLUTE | RELATIVE } <simple value specification> <fetch target list> ::= <target specification> [ { <comma> <target specification> }... ] and this must be done after "OPEN cursorname"; ---------------- Hannu
В списке pgsql-hackers по дате отправления: