Re: [HACKERS] updated patch for foreach stmt

[Tom Lane]

Stephen Frost  writes:
> * Pavel Stehule (pavel.steh...@gmail.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

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

Re: [HACKERS] updated patch for foreach stmt

[Pavel Stehule]

2011/2/16 Tom Lane :
> Andrew Dunstan  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
>

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

Re: [HACKERS] updated patch for foreach stmt

[Tom Lane]

Andrew Dunstan  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

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

Re: [HACKERS] updated patch for foreach stmt

[Andrew Dunstan]

On 02/15/2011 08:59 PM, Robert Haas wrote:

On Tue, Feb 15, 2011 at 8:44 PM, Tom Lane  wrote:

Robert Haas  writes:

On Tue, Feb 8, 2011 at 3:26 PM, Stephen Frost  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

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

Re: [HACKERS] updated patch for foreach stmt

[Stephen Frost]

* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Feb 15, 2011 at 8:44 PM, Tom Lane  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


signature.asc
Description: Digital signature

Re: [HACKERS] updated patch for foreach stmt

[Robert Haas]

On Tue, Feb 15, 2011 at 8:44 PM, Tom Lane  wrote:
> Robert Haas  writes:
>> On Tue, Feb 8, 2011 at 3:26 PM, Stephen Frost  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

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

Re: [HACKERS] updated patch for foreach stmt

[Tom Lane]

Robert Haas  writes:
> On Tue, Feb 8, 2011 at 3:26 PM, Stephen Frost  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

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

Re: [HACKERS] updated patch for foreach stmt

[Stephen Frost]

* Robert Haas (robertmh...@gmail.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


signature.asc
Description: Digital signature

Re: [HACKERS] updated patch for foreach stmt

[Stephen Frost]

* Pavel Stehule (pavel.steh...@gmail.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 
Date:   Tue Feb 8 16:15:03 2011 -0500

Add ARRAY keyword to example, ewps.

commit 34a8ffd8d4cfe42bb4f698564f16bd468b9f2613
Author: Stephen Frost 
Date:   Tue Feb 8 16:14:17 2011 -0500

Tabs are bad, mmmkay.

commit cf1ebcb7e4905cc31cd58b4fd9fa90cd488cc0c0
Author: Stephen Frost 
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
*** a/doc/src/sgml/plpgsql.sgml
--- b/doc/src/sgml/plpgsql.sgml
***
*** 300,310  $$ LANGUAGE plpgsql;
  
   All variables used in a block must be declared in the
   declarations section of the block.
!  (The only exceptions are that the loop variable of a FOR loop
!  iterating over a range of integer values is automatically declared as an
!  integer variable, and likewise the loop variable of a FOR loop
!  iterating over a cursor's result is automatically declared as a
!  record variable.)
  
  
  
--- 300,308 
  
   All variables used in a block must be declared in the
   declarations section of the block.
!  (The only exceptions are the loop variables of FOR and
!  FOREACH loops which are automatically declared as the
!  appropriate variable type to match what to loop is over.)
  
  
  
***
*** 1359,1375  GET DIAGNOSTICS integer_var = ROW_COUNT;
  

 
! A FOR statement sets FOUND true
! if it iterates one or more times, else false.  This applies to
! all four variants of the FOR statement (integer
! FOR loops, record-set FOR loops,
! dynamic record-set FOR loops, and cursor
! FOR loops).
! FOUND is set this way when the
! FOR loop exits; inside the execution of the loop,
! FOUND is not modified by the
! FOR statement, although it might be changed by the
! execution of other statements within the loop body.
 


--- 1357,1375 
  

 
! A FOR or FOREACH statement sets
! FOUND to true if it iterates one or more times,
! else to false.  This applies to all four variants of the
! FOR statement (integer FOR loops, record-set
! FOR loops, dynamic record-set FOR loops, and
! cursor FOR loops) and all variants of the
! FOREACH statement (currently only ARRAY
! FOREACH loops).  FOUND is set this
! way when the FOR or FOREACH loop exits;
! inside the execution of the loop, FOUND is not
! modified by the FOR or FOREACH statement,
! although it might be changed by the execution of other statements
! within the loop body.
 


***
*** 1910,1918  END CASE;
  
  
   With the LOOP, EXIT,
!  CONTINUE, WHILE, and FOR
!  statements, you can arrange for your PL/pgSQL
!  function to repeat a series of commands.
  
  
  
--- 1910,1918 
  
  
   With the LOOP, EXIT,
!  CONTINUE, WHILE, FOR,
!  and FOREACH statements, you can arrange for your
!  PL/pgSQL function to repeat a series of commands.
  
  
  
***
*** 2238,2243  END LOOP  label ;
--- 2238,2287 
  
 
  
+
+ Looping Through Arrays
+ 
+ 
+ Similar to a FOR loop is the FOREACH loop.
+ FOREACH is used to loop over multi-value variables, such
+ as ARRAYs.  Other multi-value variables may be added to FOREACH
+ later.  Note that FOREACH can be thought of horizantally
+ looping, whereas FOR can be thought of a vertical loop.
+ The FOREACH statement to loop over an ARRAY is:
+ 
+ 
+  <> 
+ FOREACH target  SLICE number  IN ARRAY expression LOOP
+ statements
+ END LOOP  label ;
+ 
+ 
+ This FOREACH form allows looping over each variable in an
+ array, in which case the loop variable will be the array's component
+ type (eg: the single-value loop variable for an integer ARRAY would
+ be an integer), or looping over slices of the array, in which case
+ the loop variable will be an array itself of the same type as the array.
+ Note that the SLICE is one of the dimensions of the array- it's not a
+ number of elements.  Following is an example of looping through an
+ integer array:
+ 
+ 
+ CREATE FUNCTION sum(VARIADIC int[]) RETURNS int8 AS $$
+ DECLARE
+   s int8; x int;
+ BEGIN
+   FOREACH x IN

Re: [HACKERS] updated patch for foreach stmt

[Pavel Stehule]

2011/2/8 Stephen Frost :
> * Robert Haas (robertmh...@gmail.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 
> 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-
>
>

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

Re: [HACKERS] updated patch for foreach stmt

[Pavel Stehule]

2011/2/8 Stephen Frost :
> Greetings,
>
> * Pavel Stehule (pavel.steh...@gmail.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 
> 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 
> 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 
> Date:   Tue Feb 8 14:27:05 2011 -0500
>
>    PL/PgSQL FOREACH Minor Whitespace Cleanup
>
> commit 612cf5485f202a49aec70cf32f74d19d0d130b6b
> Author: Stephen Frost 
> 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 
> 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-
>
>

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

Re: [HACKERS] updated patch for foreach stmt

[Stephen Frost]

* Robert Haas (robertmh...@gmail.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 
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
*** a/doc/src/sgml/plpgsql.sgml
--- b/doc/src/sgml/plpgsql.sgml
***
*** 300,310  $$ LANGUAGE plpgsql;
  
   All variables used in a block must be declared in the
   declarations section of the block.
!  (The only exceptions are that the loop variable of a FOR loop
!  iterating over a range of integer values is automatically declared as an
!  integer variable, and likewise the loop variable of a FOR loop
!  iterating over a cursor's result is automatically declared as a
!  record variable.)
  
  
  
--- 300,308 
  
   All variables used in a block must be declared in the
   declarations section of the block.
!  (The only exceptions are the loop variables of FOR and
!  FOREACH loops which are automatically declared as the
!  appropriate variable type to match what to loop is over.)
  
  
  
***
*** 1359,1375  GET DIAGNOSTICS integer_var = ROW_COUNT;
  

 
! A FOR statement sets FOUND true
! if it iterates one or more times, else false.  This applies to
! all four variants of the FOR statement (integer
! FOR loops, record-set FOR loops,
! dynamic record-set FOR loops, and cursor
! FOR loops).
! FOUND is set this way when the
! FOR loop exits; inside the execution of the loop,
! FOUND is not modified by the
! FOR statement, although it might be changed by the
! execution of other statements within the loop body.
 


--- 1357,1375 
  

 
! A FOR or FOREACH statement sets
! FOUND to true if it iterates one or more times,
! else to false.  This applies to all four variants of the
! FOR statement (integer FOR loops, record-set
! FOR loops, dynamic record-set FOR loops, and
! cursor FOR loops) and all variants of the
! FOREACH statement (currently only ARRAY
! FOREACH loops).  FOUND is set this
! way when the FOR or FOREACH loop exits;
! inside the execution of the loop, FOUND is not
! modified by the FOR or FOREACH statement,
! although it might be changed by the execution of other statements
! within the loop body.
 


***
*** 1910,1918  END CASE;
  
  
   With the LOOP, EXIT,
!  CONTINUE, WHILE, and FOR
!  statements, you can arrange for your PL/pgSQL
!  function to repeat a series of commands.
  
  
  
--- 1910,1918 
  
  
   With the LOOP, EXIT,
!  CONTINUE, WHILE, FOR,
!  and FOREACH statements, you can arrange for your
!  PL/pgSQL function to repeat a series of commands.
  
  
  
***
*** 2238,2243  END LOOP  label ;
--- 2238,2285 
  
 
  
+
+ Looping Through Arrays
+ 
+ 
+ Similar to a FOR loop is the FOREACH loop.
+ FOREACH is used to loop over multi-value variables, such
+ as ARRAYs.  Other multi-value variables may be added to FOREACH
+ later.  Note that FOREACH can be thought of horizantally
+ looping, whereas FOR can be thought of a vertical loop.
+ The FOREACH statement to loop over an ARRAY is:
+ 
+ 
+  <> 
+ FOREACH target  SCALE number  IN expression LOOP
+ statements
+ END LOOP  label ;
+ 
+ 
+ This FOREACH form allows looping over each variable in an
+ array, in which case the loop variable will be the array's component
+ type (eg: the single-value loop variable for an integer ARRAY would
+ be an integer), or looping over segments of the array, in which case
+ the loop variable will be an array itself of the same type as the array.
+ Following is an example of looping through an integer array:
+ 
+ 
+ CREATE FUNCTION sum(VARIADIC int[]) RETURNS int8 AS $$
+ DECLARE
+   s int8; x int;
+ BEGIN
+   FOREACH x IN $1
+   LOOP
+ 

Re: [HACKERS] updated patch for foreach stmt

[Robert Haas]

On Tue, Feb 8, 2011 at 3:26 PM, Stephen Frost  wrote:
> Greetings,
>
> * Pavel Stehule (pavel.steh...@gmail.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

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

Re: [HACKERS] updated patch for foreach stmt

[Stephen Frost]

Greetings,

* Pavel Stehule (pavel.steh...@gmail.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 
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 
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 
Date:   Tue Feb 8 14:27:05 2011 -0500

PL/PgSQL FOREACH Minor Whitespace Cleanup

commit 612cf5485f202a49aec70cf32f74d19d0d130b6b
Author: Stephen Frost 
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 
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
*** a/doc/src/sgml/plpgsql.sgml
--- b/doc/src/sgml/plpgsql.sgml
***
*** 300,310  $$ LANGUAGE plpgsql;
  
   All variables used in a block must be declared in the
   declarations section of the block.
!  (The only exceptions are that the loop variable of a FOR loop
!  iterating over a range of integer values is automatically declared as an
!  integer variable, and likewise the loop variable of a FOR loop
!  iterating over a cursor's result is automatically declared as a
!  record variable.)
  
  
  
--- 300,308 
  
   All variables used in a block must be declared in the
   declarations section of the block.
!  (The only exceptions are the loop variables of FOR and
!  FOREACH loops which are automatically declared as the
!  appropriate variable type to match what to loop is over.)
  
  
  
***
*** 1359,1375  GET DIAGNOSTICS integer_var = ROW_COUNT;
  

 
! A FOR statement sets FOUND true
! if it iterates one or more times, else false.  This applies to
! all four variants of the FOR statement (integer
! FOR loops, record-set FOR loops,
! dynamic record-set FOR loops, and cursor
! FOR loops).
! FOUND is set this way when the
! FOR loop exits; inside the execution of the loop,
! FOUND is not modified by the
! FOR statement, although it might be changed by the
! execution of other statements within the loop body.
 


--- 1357,1375 
  

 
! A FOR or FOREACH statement sets
! FOUND to true if it iterates one or more times,
! else to false.  This applies to all four variants of the
! FOR statement (integer FOR loops, record-set
! FOR loops, dynamic record-set FOR loops, and
! cursor FOR loops) and all variants of the
! FOREACH statement (currently only ARRAY
! FOREACH loops).  FOUND is set this
! way when the FOR or FOREACH loop exits;
! inside the execution of the loop, FOUND is not
! modified by the FOR or FOREACH statement,
! although it might be changed by the execution of other statements
! within the loop body.
 


***
*** 1910,1918  END CASE;
  
  
   With the LOOP, E

[HACKERS] updated patch for foreach stmt

[Pavel Stehule]

Hello

I resend a patch with last update of this patch

Regards

Pavel Stehule
*** ./doc/src/sgml/plpgsql.sgml.orig	2011-01-30 10:04:52.097002835 +0100
--- ./doc/src/sgml/plpgsql.sgml	2011-01-30 10:05:21.379877524 +0100
***
*** 2238,2243 
--- 2238,2268 
  
 
  
+
+ Looping Through Array
+ 
+  <> 
+ FOREACH target  SCALE number  IN expression LOOP
+ statements
+ END LOOP  label ;
+ 
+ 
+ 
+ CREATE FUNCTION sum(VARIADIC int[]) RETURNS int8 AS $$
+ DECLARE
+   s int8; x int;
+ BEGIN
+   FOREACH x IN $1
+   LOOP
+ s := s + x;
+   END LOOP;
+   RETURN s;
+ END;
+ $$ LANGUAGE plpgsql;
+ 
+ 
+
+ 
 
  Trapping Errors
  
*** ./src/backend/utils/adt/arrayfuncs.c.orig	2011-01-29 12:52:53.109667995 +0100
--- ./src/backend/utils/adt/arrayfuncs.c	2011-01-30 10:05:21.390878981 +0100
***
*** 68,74 
  			 Datum *values, bool *nulls, int nitems,
  			 int typlen, bool typbyval, char typalign,
  			 bool freedata);
- static bool array_get_isnull(const bits8 *nullbitmap, int offset);
  static void array_set_isnull(bits8 *nullbitmap, int offset, bool isNull);
  static Datum ArrayCast(char *value, bool byval, int len);
  static int ArrayCastAndSet(Datum src,
--- 68,73 
***
*** 3840,3846 
   * nullbitmap: pointer to array's null bitmap (NULL if none)
   * offset: 0-based linear element number of array element
   */
! static bool
  array_get_isnull(const bits8 *nullbitmap, int offset)
  {
  	if (nullbitmap == NULL)
--- 3839,3845 
   * nullbitmap: pointer to array's null bitmap (NULL if none)
   * offset: 0-based linear element number of array element
   */
! bool
  array_get_isnull(const bits8 *nullbitmap, int offset)
  {
  	if (nullbitmap == NULL)
*** ./src/include/utils/array.h.orig	2011-01-30 10:04:52.142008793 +0100
--- ./src/include/utils/array.h	2011-01-30 10:05:21.404880832 +0100
***
*** 215,220 
--- 215,221 
  extern ArrayType *array_set(ArrayType *array, int nSubscripts, int *indx,
  		  Datum dataValue, bool isNull,
  		  int arraytyplen, int elmlen, bool elmbyval, char elmalign);
+ extern bool array_get_isnull(const bits8 *nullbitmap, int offset);
  extern ArrayType *array_get_slice(ArrayType *array, int nSubscripts,
  int *upperIndx, int *lowerIndx,
  int arraytyplen, int elmlen, bool elmbyval, char elmalign);
*** ./src/pl/plpgsql/src/gram.y.orig	2011-01-30 10:04:52.158010906 +0100
--- ./src/pl/plpgsql/src/gram.y	2011-01-30 10:05:21.408881362 +0100
***
*** 21,26 
--- 21,27 
  #include "parser/parse_type.h"
  #include "parser/scanner.h"
  #include "parser/scansup.h"
+ #include "utils/array.h"
  
  
  /* Location tracking support --- simpler than bison's default */
***
*** 134,139 
--- 135,141 
  			PLpgSQL_datum   *scalar;
  			PLpgSQL_rec *rec;
  			PLpgSQL_row *row;
+ 			int	slice;
  		}		forvariable;
  		struct
  		{
***
*** 178,184 
  %type 	assign_var
  %type 		cursor_variable
  %type 	decl_cursor_arg
! %type 	for_variable
  %type 	for_control
  
  %type 		any_identifier opt_block_label opt_label
--- 180,186 
  %type 	assign_var
  %type 		cursor_variable
  %type 	decl_cursor_arg
! %type 	for_variable foreach_control
  %type 	for_control
  
  %type 		any_identifier opt_block_label opt_label
***
*** 190,196 
  %type 	stmt_return stmt_raise stmt_execsql
  %type 	stmt_dynexecute stmt_for stmt_perform stmt_getdiag
  %type 	stmt_open stmt_fetch stmt_move stmt_close stmt_null
! %type 	stmt_case
  
  %type 	proc_exceptions
  %type  exception_sect
--- 192,198 
  %type 	stmt_return stmt_raise stmt_execsql
  %type 	stmt_dynexecute stmt_for stmt_perform stmt_getdiag
  %type 	stmt_open stmt_fetch stmt_move stmt_close stmt_null
! %type 	stmt_case stmt_foreach_a
  
  %type 	proc_exceptions
  %type  exception_sect
***
*** 264,269 
--- 266,272 
  %token 	K_FETCH
  %token 	K_FIRST
  %token 	K_FOR
+ %token 	K_FOREACH
  %token 	K_FORWARD
  %token 	K_FROM
  %token 	K_GET
***
*** 298,303 
--- 301,307 
  %token 	K_ROWTYPE
  %token 	K_ROW_COUNT
  %token 	K_SCROLL
+ %token 	K_SLICE
  %token 	K_SQLSTATE
  %token 	K_STRICT
  %token 	K_THEN
***
*** 739,744 
--- 743,750 
  		{ $$ = $1; }
  | stmt_for
  		{ $$ = $1; }
+ | stmt_foreach_a
+ 		{ $$ = $1; }
  | stmt_exit
  		{ $$ = $1; }
  | stmt_return
***
*** 1386,1391 
--- 1392,1455 
  	}
  ;
  
+ stmt_foreach_a		: opt_block_label K_FOREACH foreach_control K_IN expr_until_loop loop_body
+ 	{
+ 		PLpgSQL_stmt_foreach_a *new = palloc0(sizeof(PLpgSQL_stmt_foreach_a));
+ 		new->cmd_type = PLPGSQL_STMT_FOREACH_A;
+ 		new->lineno = plpgsql_location_to_lineno(@2);
+ 		new->label = $1;
+ 		new->expr = $5;
+ 		new->slice = $3.slice;
+ 		new->body = $6.stmts;
+ 
+ 		if ($3.rec)
+ 		{
+ 			new->rec = $3.rec;
+ 			check_as