Re: 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/

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(at)momjian(dot)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(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

>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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +