Thread: actualised forgotten Magnus's patch for plpgsql MOVE statement
Hello I refreshed Magnus's patch http://archives.postgresql.org/pgsql-patches/2007-02/msg00275.php from februar. Regards Pavel Stehule 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. _________________________________________________________________ Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/
Attachment
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---------------------------------------------------------------------------
Pavel Stehule wrote:
> Hello
>
> I refreshed Magnus's patch
> http://archives.postgresql.org/pgsql-patches/2007-02/msg00275.php from
> februar.
>
> Regards
>
> Pavel Stehule
>
> 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.
>
> _________________________________________________________________
> Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/
[ Attachment, skipping... ]
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
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
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
>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. > It's question. There are lot of links to FETCH in doc, and we support from FETCH direction only subset. It needs at least notice in documentation. When I testeid MOVE I found an form MOVE FORWARD 10 ... more natural than MOVE RELATIVE 10 and if we support MOVE FORWARD ... then is logic support MOVE FORWARD n , else FORWARD, BACKWARD are nonstandard and MOVE statement too. Regards Pavel Stehule _________________________________________________________________ Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com. http://www.msn.cz/
Pavel Stehule wrote: > > >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. > > > > It's question. There are lot of links to FETCH in doc, and we support from > FETCH direction only subset. It needs at least notice in documentation. When > I testeid MOVE I found an form > MOVE FORWARD 10 ... more natural than MOVE RELATIVE 10 and if we support > MOVE FORWARD ... then is logic support MOVE FORWARD n , > > else FORWARD, BACKWARD are nonstandard and MOVE statement too. Do we have a patch to make this consistent? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
> > Do we have a patch to make this consistent? > no, not yet. It's topic for discussion and ToDo Regards Pavel Stehule
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---------------------------------------------------------------------------
Pavel Stehule wrote:
>
> >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.
> >
>
> It's question. There are lot of links to FETCH in doc, and we support from
> FETCH direction only subset. It needs at least notice in documentation. When
> I testeid MOVE I found an form
> MOVE FORWARD 10 ... more natural than MOVE RELATIVE 10 and if we support
> MOVE FORWARD ... then is logic support MOVE FORWARD n ,
>
> else FORWARD, BACKWARD are nonstandard and MOVE statement too.
>
> Regards
> Pavel Stehule
>
> _________________________________________________________________
> Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com.
> http://www.msn.cz/
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Added to TODO for pl/pgsql: o Review handling of MOVE and FETCH http://archives.postgresql.org/pgsql-patches/2007-04/msg00527.php --------------------------------------------------------------------------- Pavel Stehule wrote: > > >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. > > > > It's question. There are lot of links to FETCH in doc, and we support from > FETCH direction only subset. It needs at least notice in documentation. When > I testeid MOVE I found an form > MOVE FORWARD 10 ... more natural than MOVE RELATIVE 10 and if we support > MOVE FORWARD ... then is logic support MOVE FORWARD n , > > else FORWARD, BACKWARD are nonstandard and MOVE statement too. > > Regards > Pavel Stehule > > _________________________________________________________________ > Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com. > http://www.msn.cz/ > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +