Hello

I refreshed Magnus's patch
http://archives.postgresql.org/pgsql...2/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/


---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

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...2/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. +

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Fri, 2007-04-20 at 09:46 +0200, Pavel Stehule wrote:
> I refreshed Magnus's patch
> http://archives.postgresql.org/pgsql...2/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



---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

>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

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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

>
> Do we have a patch to make this consistent?
>

no, not yet. It's topic for discussion and ToDo

Regards
Pavel Stehule

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Added to TODO for pl/pgsql:

o Review handling of MOVE and FETCH

http://archives.postgresql.org/pgsql...4/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. +

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches