Skip site navigation (1) Skip section navigation (2)

Re: actualised forgotten Magnus's patch for plpgsql MOVE statement

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)hotmail(dot)com>, pgsql-patches(at)postgresql(dot)org, bruce(at)momjian(dot)us, magnus(at)hagander(dot)net
Subject: Re: actualised forgotten Magnus's patch for plpgsql MOVE statement
Date: 2007-04-29 03:37:41
Message-ID: 17697.1177817861@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Neil Conway <neilc(at)samurai(dot)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

In response to

Responses

pgsql-patches by date

Next:From: Pavel StehuleDate: 2007-04-29 05:40:35
Subject: Re: actualised forgotten Magnus's patch for plpgsql MOVE statement
Previous:From: Neil ConwayDate: 2007-04-29 01:27:32
Subject: Re: actualised forgotten Magnus's patch for plpgsql MOVEstatement

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group