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

Re: actualised forgotten Magnus's patch for plpgsql MOVEstatement

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 MOVEstatement
Date: 2007-04-29 01:27:32
Message-ID: 1177810052.6440.196.camel@localhost.localdomain (view raw or flat)
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

pgsql-patches by date

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

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