Re: MOVE strangeness

"Jeroen T. Vermeulen" <jtv(at)xs4all(dot)nl> writes:
> Here's something that's been bothering me for a while... Perhaps this
> is correct behaviour, but I can't quite see how.

It looks fine to me, given the underlying model of how a cursor works,
which probably isn't really written down anywhere :-(. Briefly:

1. A cursor can be positioned before the first row, after the last row,
or on any individual row of its SELECT result. The initial state is
before the first row.

2. "FETCH 1" advances the cursor one row (if possible), and if it's not
now after the last row, returns the row the cursor is now on. "FETCH n"
repeats this operation n times.

3. "FETCH BACKWARD 1" (or FETCH -1) moves the cursor back one row (if
possible), and if it's not now before the first row, returns the row the
cursor is now on. "FETCH -n" repeats this operation n times.

4. The result count is the number of rows successfully returned (or for
MOVE, the number that would have been returned by the equivalent FETCH).

> This makes it a bit hard for me to figure out just how far I moved my
> cursor backwards! Moving by BACKWARD ALL will give me the same result
> as moving by -3.

If the return count is not the same as abs(n), then you ran off the end
of the result, and are now positioned before the start or after the end
depending on the requested direction. If the return count is the same
as abs(n), then you are positioned on a real row. This doesn't seem any
more confusing to me than any other convention that might have been
picked.

> This does not happen
> if I replace the FETCHes by MOVEs.

I'm a little confused by that remark; it seems to me that FETCH and MOVE
have identical behaviors so far as repositioning the cursor is concerned.
(Internally, MOVE *is* a FETCH, it just suppresses output of the rows.)
Can you give an example where you get different behavior?

regards, tom lane