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

From: Neil Conway <neilc(at)samurai(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)hotmail(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org, bruce(at)momjian(dot)us, tgl(at)sss(dot)pgh(dot)pa(dot)us, magnus(at)hagander(dot)net
Subject: Re: actualised forgotten Magnus's patch for plpgsql MOVE statement
Date: 2007-04-29 01:27:32
Message-ID: 1177810052.6440.196.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

On Fri, 2007-04-20 at 09:46 +0200, Pavel Stehule wrote:
> I refreshed Magnus's patch
> http://archives.postgresql.org/pgsql-patches/2007-02/msg00275.php from
> februar.

Applied, thanks.

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. Is this the best behavior? At the least, we should describe
it in the documentation.

> 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.

-Neil

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2007-04-29 03:37:41 Re: actualised forgotten Magnus's patch for plpgsql MOVE statement
Previous Message Neil Conway 2007-04-28 22:47:10 Re: Hash function for numeric (WIP)