Neil Conway <neilc@samurai.com> writes:
> BTW, I notice that the documentation for PL/PgSQL's FETCH command states
> that only the direction variants that fetch a *single* row are allowed.
> This is not actually the case: FETCH RELATIVE 2 FROM c INTO v results in
> assigning the first row from "c" into "v", and then discarding the
> second row.
What? That's not what it did when I was reviewing the code. It should
skip one row and assign the second one to v.
>> p.s. scrollable cursors in plpgsql need little work still. I forgot for
>> nonstandard (postgresql extension) direction forward all, forward n,
>> backward n. Forward all propably hasn't sense.
> Yes, these are certainly needed for MOVE, and we may as well allow them
> for FETCH as well.
No, because these variants specify returning multiple rows, which is
exactly what plpgsql doesn't support. FETCH FORWARD 2 and FETCH
RELATIVE 2 are *entirely* different animals, and we shouldn't confuse
them. If we do, we'll regret it someday when we'd like to actually
offer that functionality somehow in plpgsql.
I would argue that we should likewise not allow them in plpgsql's MOVE,
although this is more of a judgment call than is the case for FETCH.
I just don't think it's a good idea to provide two redundant ways to do
the same thing, when we might want to make one of the ways mean
something else later. There's no upside and there might be a downside.
regards, tom lane
