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
