updated patch for foreach stmt

Hello

I resend a patch with last update of this patch

Regards

Pavel Stehule

Greetings,

* Pavel Stehule (pavel(dot)stehule(at)gmail(dot)com) wrote:
> I resend a patch with last update of this patch

Alright, so, like I said, I really like this feature and would like to
see it included. To that end, I've done perhaps a bit more than a
review of the patch. Pavel, if you could go over the changes I've made
and review them and let me know if you see any problems, I'd appreciate
it. I've tried to get it ready for a committer as much as I can without
being one. :)

I moved the array iteration over into arrayfuncs.c, cleaned it up quite
a bit, cleaned up the pl/pgsql foreach function, improved the PL/PgSQL
documentation to understand FOREACH as another top-level command, added
comments all over the place, etc.

Passes all regressions too.

commit 19deaf69a4dabfa4a223a6dcd36570866ad0bd3c
Author: Stephen Frost <sfrost(at)snowman(dot)net>
Date: Tue Feb 8 15:15:48 2011 -0500

PL/PgSQL FOREACH cleanup

Define and rename element OID to be more consistant, ensure
that the right name gets returned in error messages, and fix
regression output to match new error message (grammar cleanup).

commit f88fd2ab5419f9a2784677038b3fb01053c69163
Merge: f191af1 8c6e3ad
Author: Stephen Frost <sfrost(at)snowman(dot)net>
Date: Tue Feb 8 14:28:18 2011 -0500

Merge branch 'master' of git://git.postgresql.org/git/postgresql into plpgsql_foreach

commit f191af16f9d3e5ae0072e61c1b58713040cc8d64
Author: Stephen Frost <sfrost(at)snowman(dot)net>
Date: Tue Feb 8 14:27:05 2011 -0500

PL/PgSQL FOREACH Minor Whitespace Cleanup

commit 612cf5485f202a49aec70cf32f74d19d0d130b6b
Author: Stephen Frost <sfrost(at)snowman(dot)net>
Date: Tue Feb 8 14:06:06 2011 -0500

Improving FOREACH, code and documentation

This patch moves and reworks much of the array iteration code
that FOREACH had been implemented with to be part of arrayfuncs.c
and exported through utils/array.h. It also cleans up the error
handling and set up pieces of the FOREACH handling in pl_exec.c
Lastly, the documentation and comments are updated and improved.

commit 89058b79e43311e8f37af16c3fc17b622dc97578
Author: Stephen Frost <sfrost(at)snowman(dot)net>
Date: Sun Feb 6 14:14:04 2011 -0500

Add FOREACH top-level PL/PgSQL command

This patch adds a new top-level PL/PgSQL command called FOREACH which
is intended to be for iterating over multi-value variables. This also
includes the first FOREACH type, an ARRAY iteration capability.

Patch by Pavel Stehule.

Thanks,

Stephen

On Tue, Feb 8, 2011 at 3:26 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> Greetings,
>
> * Pavel Stehule (pavel(dot)stehule(at)gmail(dot)com) wrote:
>> I resend a patch with last update of this patch
>
> Alright, so, like I said, I really like this feature and would like to
> see it included.  To that end, I've done perhaps a bit more than a
> review of the patch.  Pavel, if you could go over the changes I've made
> and review them and let me know if you see any problems, I'd appreciate
> it.  I've tried to get it ready for a committer as much as I can without
> being one. :)

Amen to that!

I think the syntax Tom suggested before was FOREACH thingy IN ARRAY
arr rather than just FOREACH thingy IN arr. That's probably a good
idea, because it gives us an escape hatch against needing to invent
yet another variant of this syntax - the word immediately following IN
can be known with confidence to be intended as a keyword rather than
as part of the expression.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

2011/2/8 Stephen Frost <sfrost(at)snowman(dot)net>:
> Greetings,
>
> * Pavel Stehule (pavel(dot)stehule(at)gmail(dot)com) wrote:
>> I resend a patch with last update of this patch
>
> Alright, so, like I said, I really like this feature and would like to
> see it included.  To that end, I've done perhaps a bit more than a
> review of the patch.  Pavel, if you could go over the changes I've made
> and review them and let me know if you see any problems, I'd appreciate
> it.  I've tried to get it ready for a committer as much as I can without
> being one. :)
>
> I moved the array iteration over into arrayfuncs.c, cleaned it up quite
> a bit, cleaned up the pl/pgsql foreach function, improved the PL/PgSQL
> documentation to understand FOREACH as another top-level command, added
> comments all over the place, etc.
>

It's looking well - thank you.

There is only bad keywords in doc - SCALE instead SLICE and a maybe a
usage of slicing need a example.

It is nice.

Regards

Pavel Stehule

> Passes all regressions too.
>
> commit 19deaf69a4dabfa4a223a6dcd36570866ad0bd3c
> Author: Stephen Frost <sfrost(at)snowman(dot)net>
> Date:   Tue Feb 8 15:15:48 2011 -0500
>
>    PL/PgSQL FOREACH cleanup
>
>    Define and rename element OID to be more consistant, ensure
>    that the right name gets returned in error messages, and fix
>    regression output to match new error message (grammar cleanup).
>
> commit f88fd2ab5419f9a2784677038b3fb01053c69163
> Merge: f191af1 8c6e3ad
> Author: Stephen Frost <sfrost(at)snowman(dot)net>
> Date:   Tue Feb 8 14:28:18 2011 -0500
>
>    Merge branch 'master' of git://git.postgresql.org/git/postgresql into plpgsql_foreach
>
> commit f191af16f9d3e5ae0072e61c1b58713040cc8d64
> Author: Stephen Frost <sfrost(at)snowman(dot)net>
> Date:   Tue Feb 8 14:27:05 2011 -0500
>
>    PL/PgSQL FOREACH Minor Whitespace Cleanup
>
> commit 612cf5485f202a49aec70cf32f74d19d0d130b6b
> Author: Stephen Frost <sfrost(at)snowman(dot)net>
> Date:   Tue Feb 8 14:06:06 2011 -0500
>
>    Improving FOREACH, code and documentation
>
>    This patch moves and reworks much of the array iteration code
>    that FOREACH had been implemented with to be part of arrayfuncs.c
>    and exported through utils/array.h.  It also cleans up the error
>    handling and set up pieces of the FOREACH handling in pl_exec.c
>    Lastly, the documentation and comments are updated and improved.
>
> commit 89058b79e43311e8f37af16c3fc17b622dc97578
> Author: Stephen Frost <sfrost(at)snowman(dot)net>
> Date:   Sun Feb 6 14:14:04 2011 -0500
>
>    Add FOREACH top-level PL/PgSQL command
>
>    This patch adds a new top-level PL/PgSQL command called FOREACH which
>    is intended to be for iterating over multi-value variables.  This also
>    includes the first FOREACH type, an ARRAY iteration capability.
>
>    Patch by Pavel Stehule.
>
>                Thanks,
>
>                        Stephen
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk1Rpu8ACgkQrzgMPqB3kiiuTQCfdY8Cwg5DVuvu2xKpcv6M7QQ1
> +TwAnR5ZFXsGdAwgHwQEprcYIlp8t0wy
> =DAjZ
> -----END PGP SIGNATURE-----
>
>

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> Amen to that!

Hopefully it helped. :)

> I think the syntax Tom suggested before was FOREACH thingy IN ARRAY
> arr rather than just FOREACH thingy IN arr. That's probably a good
> idea, because it gives us an escape hatch against needing to invent
> yet another variant of this syntax - the word immediately following IN
> can be known with confidence to be intended as a keyword rather than
> as part of the expression.

Alright, alright, *I* don't care that much, though I do feel it's a bit
excessive. Updated patch against HEAD attached.

commit a5d32fa41fbbbd9ace465f62be714366990061d4
Author: Stephen Frost <sfrost(at)snowman(dot)net>
Date: Tue Feb 8 15:57:40 2011 -0500

PL/PgSQL FOREACH - Add ARRAY keyword

Add ARRAY as required after IN when using FOREACH, to
future-proof against later kinds of FOREACH commands.

Thanks,

Stephen

2011/2/8 Stephen Frost <sfrost(at)snowman(dot)net>:
> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
>> Amen to that!
>
> Hopefully it helped. :)
>
>> I think the syntax Tom suggested before was FOREACH thingy IN ARRAY
>> arr rather than just FOREACH thingy IN arr.  That's probably a good
>> idea, because it gives us an escape hatch against needing to invent
>> yet another variant of this syntax - the word immediately following IN
>> can be known with confidence to be intended as a keyword rather than
>> as part of the expression.
>
> Alright, alright, *I* don't care that much, though I do feel it's a bit
> excessive.  Updated patch against HEAD attached.

I am thinking so it is good idea. Even I have no plans to expand
plpgsql in next year :), it really opening a doors for later changes.
And it's more secure - we can check if parameter is really array or
some else.

Regards

Pavel Stehule

>
> commit a5d32fa41fbbbd9ace465f62be714366990061d4
> Author: Stephen Frost <sfrost(at)snowman(dot)net>
> Date:   Tue Feb 8 15:57:40 2011 -0500
>
>    PL/PgSQL FOREACH - Add ARRAY keyword
>
>    Add ARRAY as required after IN when using FOREACH, to
>    future-proof against later kinds of FOREACH commands.
>
>        Thanks,
>
>                Stephen
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk1RrtUACgkQrzgMPqB3kigt6gCffjFcE4ddo76ECj+kB+iaM7DV
> c2UAnRDMh1B7r+4ZrnJtIeoRUXJy42+f
> =ZwQa
> -----END PGP SIGNATURE-----
>
>

* Pavel Stehule (pavel(dot)stehule(at)gmail(dot)com) wrote:
> There is only bad keywords in doc - SCALE instead SLICE and a maybe a
> usage of slicing need a example.

Err, yeah, a couple of stupid documentation issues, sorry about that.

commit 9460c0831f5de71e31823b7e9d8511d2d8124776
Author: Stephen Frost <sfrost(at)snowman(dot)net>
Date: Tue Feb 8 16:15:03 2011 -0500

Add ARRAY keyword to example, ewps.

commit 34a8ffd8d4cfe42bb4f698564f16bd468b9f2613
Author: Stephen Frost <sfrost(at)snowman(dot)net>
Date: Tue Feb 8 16:14:17 2011 -0500

Tabs are bad, mmmkay.

commit cf1ebcb7e4905cc31cd58b4fd9fa90cd488cc0c0
Author: Stephen Frost <sfrost(at)snowman(dot)net>
Date: Tue Feb 8 16:13:22 2011 -0500

PL/PgSQL documentation cleanups

SCALE -> SLICE (no clue where SCALE came from..) and clarify
what a SLICE is, really.

Thanks,

Stephen

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> I think the syntax Tom suggested before was FOREACH thingy IN ARRAY
> arr rather than just FOREACH thingy IN arr. That's probably a good
> idea, because it gives us an escape hatch against needing to invent
> yet another variant of this syntax - the word immediately following IN
> can be known with confidence to be intended as a keyword rather than
> as part of the expression.

Alright, so, for lack of anything better to do, I went ahead and marked
it Ready for Committer. If that was wrong or someone wants to do
another review, etc, let me know..

Thanks,

Stephen

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Feb 8, 2011 at 3:26 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>> Alright, so, like I said, I really like this feature and would like to
>> see it included.

> Amen to that!

> I think the syntax Tom suggested before was FOREACH thingy IN ARRAY
> arr rather than just FOREACH thingy IN arr.

Actually, I'm on record as saying the opposite: we shouldn't need to
distinguish the exact data type at the syntax level, so long as the
FOREACH construct is understood to mean "iterate through the members of
the composite object produced by this expression":

http://archives.postgresql.org/pgsql-hackers/2010-12/msg01579.php

I am not, however, wedded to that position --- if people are happier
with explicit use of ARRAY here, I won't fight hard to get rid of it.

Anyway I'm going to start on this patch next, so last chance for
opinions about the syntax ...

regards, tom lane

On Tue, Feb 15, 2011 at 8:44 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Feb 8, 2011 at 3:26 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>>> Alright, so, like I said, I really like this feature and would like to
>>> see it included.
>
>> Amen to that!
>
>> I think the syntax Tom suggested before was FOREACH thingy IN ARRAY
>> arr rather than just FOREACH thingy IN arr.
>
> Actually, I'm on record as saying the opposite: we shouldn't need to
> distinguish the exact data type at the syntax level, so long as the
> FOREACH construct is understood to mean "iterate through the members of
> the composite object produced by this expression":
>
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01579.php
>
> I am not, however, wedded to that position --- if people are happier
> with explicit use of ARRAY here, I won't fight hard to get rid of it.
>
> Anyway I'm going to start on this patch next, so last chance for
> opinions about the syntax ...

Oh, I was looking at this one:

http://archives.postgresql.org/pgsql-hackers/2010-12/msg01557.php

Anyhoo, forcing the explicit ARRAY keyword in there seems like pretty
cheap future-proofing to me. YMMV.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Tue, Feb 15, 2011 at 8:44 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Anyway I'm going to start on this patch next, so last chance for
> > opinions about the syntax ...
>
> Oh, I was looking at this one:
>
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01557.php
>
> Anyhoo, forcing the explicit ARRAY keyword in there seems like pretty
> cheap future-proofing to me. YMMV.

+1 for this, I don't see it as a big deal, and I would hate to discover
there's some reason we care (I dunno, implicit casts from ARRAY to
hstore ?) in the future that we're not thinking about now.

This also means there's no ambiguity as to what the iterator variable
should be declared as- if you're doing a FOREACH .. ARRAY, then your
iterator is an ARRAY (if it's not a scalar, of course), full stop.

Thanks,

Stephen

On 02/15/2011 08:59 PM, Robert Haas wrote:
> On Tue, Feb 15, 2011 at 8:44 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas<robertmhaas(at)gmail(dot)com> writes:
>>> On Tue, Feb 8, 2011 at 3:26 PM, Stephen Frost<sfrost(at)snowman(dot)net> wrote:
>>>> Alright, so, like I said, I really like this feature and would like to
>>>> see it included.
>>> Amen to that!
>>> I think the syntax Tom suggested before was FOREACH thingy IN ARRAY
>>> arr rather than just FOREACH thingy IN arr.
>> Actually, I'm on record as saying the opposite: we shouldn't need to
>> distinguish the exact data type at the syntax level, so long as the
>> FOREACH construct is understood to mean "iterate through the members of
>> the composite object produced by this expression":
>>
>> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01579.php
>>
>> I am not, however, wedded to that position --- if people are happier
>> with explicit use of ARRAY here, I won't fight hard to get rid of it.
>>
>> Anyway I'm going to start on this patch next, so last chance for
>> opinions about the syntax ...
> Oh, I was looking at this one:
>
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01557.php
>
> Anyhoo, forcing the explicit ARRAY keyword in there seems like pretty
> cheap future-proofing to me. YMMV.
>

If this is the syntax that makes you do things like:

FOREACH foo IN ARRAY ARRAY[1,2,3]

I have to say I find that pretty darn ugly still.

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 02/15/2011 08:59 PM, Robert Haas wrote:
>> Anyhoo, forcing the explicit ARRAY keyword in there seems like pretty
>> cheap future-proofing to me. YMMV.

> If this is the syntax that makes you do things like:
> FOREACH foo IN ARRAY ARRAY[1,2,3]
> I have to say I find that pretty darn ugly still.

Yeah, that was the argument against requiring ARRAY. So it comes down
to whether you think we need future-proofing here. I can't immediately
see any reason for us to need a keyword right there, but ...

regards, tom lane

2011/2/16 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> On 02/15/2011 08:59 PM, Robert Haas wrote:
>>> Anyhoo, forcing the explicit ARRAY keyword in there seems like pretty
>>> cheap future-proofing to me.  YMMV.
>
>> If this is the syntax that makes you do things like:
>>      FOREACH foo IN ARRAY ARRAY[1,2,3]
>> I have to say I find that pretty darn ugly still.
>
> Yeah, that was the argument against requiring ARRAY.  So it comes down
> to whether you think we need future-proofing here.  I can't immediately
> see any reason for us to need a keyword right there, but ...

the combination of two keywords isn't nice, but we can ensure so
result of expression will has a requested type. It's more verbose,
it's more secure. We can to check a allowed keywords like SCALING in
compile time, we can use a more keywords - A hash type can need a
separation between KEY and VALUE - so any keyword there enables a
higher possibilities in future. We can do it without a auxiliary
keyword too, but parser will be more complex.

Regards

Pavel Stehule

>
>                        regards, tom lane
>

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Pavel Stehule (pavel(dot)stehule(at)gmail(dot)com) wrote:
>> There is only bad keywords in doc - SCALE instead SLICE and a maybe a
>> usage of slicing need a example.

> Err, yeah, a couple of stupid documentation issues, sorry about that.

Applied with assorted cleanup. I left the syntax as-is, since that
seems to be the plurality position at the moment.

regards, tom lane