Re: [HACKERS] updated patch for foreach stmt
Robert Haas robertmh...@gmail.com writes: On Tue, Feb 8, 2011 at 3:26 PM, Stephen Frost sfr...@snowman.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 -- 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
On Tue, Feb 15, 2011 at 8:44 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Tue, Feb 8, 2011 at 3:26 PM, Stephen Frost sfr...@snowman.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 -- 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
* Robert Haas (robertmh...@gmail.com) wrote: On Tue, Feb 15, 2011 at 8:44 PM, Tom Lane t...@sss.pgh.pa.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 signature.asc Description: Digital signature
Re: [HACKERS] updated patch for foreach stmt
On 02/15/2011 08:59 PM, Robert Haas wrote: On Tue, Feb 15, 2011 at 8:44 PM, Tom Lanet...@sss.pgh.pa.us wrote: Robert Haasrobertmh...@gmail.com writes: On Tue, Feb 8, 2011 at 3:26 PM, Stephen Frostsfr...@snowman.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 -- 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 and...@dunslane.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 -- 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
2011/2/16 Tom Lane t...@sss.pgh.pa.us: Andrew Dunstan and...@dunslane.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 -- 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 sfr...@snowman.net 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
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 sfr...@snowman.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 sfr...@snowman.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 sfr...@snowman.net Date: Tue Feb 8 14:27:05 2011 -0500 PL/PgSQL FOREACH Minor Whitespace Cleanup commit 612cf5485f202a49aec70cf32f74d19d0d130b6b Author: Stephen Frost sfr...@snowman.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 sfr...@snowman.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 *** a/doc/src/sgml/plpgsql.sgml --- b/doc/src/sgml/plpgsql.sgml *** *** 300,310 $$ LANGUAGE plpgsql; para 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 literalFOR/ loop ! iterating over a range of integer values is automatically declared as an ! integer variable, and likewise the loop variable of a literalFOR/ loop ! iterating over a cursor's result is automatically declared as a ! record variable.) /para para --- 300,308 para All variables used in a block must be declared in the declarations section of the block. ! (The only exceptions are the loop variables of literalFOR/ and ! literalFOREACH/ loops which are automatically declared as the ! appropriate variable type to match what to loop is over.) /para para *** *** 1359,1375 GET DIAGNOSTICS integer_var = ROW_COUNT; listitem para ! A commandFOR/ statement sets literalFOUND/literal true ! if it iterates one or more times, else false. This applies to ! all four variants of the commandFOR/ statement (integer ! commandFOR/ loops, record-set commandFOR/ loops, ! dynamic record-set commandFOR/ loops, and cursor ! commandFOR/ loops). ! literalFOUND/literal is set this way when the ! commandFOR/ loop exits; inside the execution of the loop, ! literalFOUND/literal is not modified by the ! commandFOR/ statement, although it might be changed by the ! execution of other statements within the loop body. /para /listitem listitem --- 1357,1375 listitem para ! A commandFOR/ or commandFOREACH/ statement sets ! literalFOUND/literal to true if it iterates one or more times, ! else to false. This applies to all four variants of the ! commandFOR/ statement (integer commandFOR/ loops, record-set ! commandFOR/ loops, dynamic record-set commandFOR/ loops, and ! cursor commandFOR/ loops) and all variants of the ! commandFOREACH/ statement (currently only ARRAY ! commandFOREACH/ loops). literalFOUND/literal is set this
Re: [HACKERS] updated patch for foreach stmt
On Tue, Feb 8, 2011 at 3:26 PM, Stephen Frost sfr...@snowman.net 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
* 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 sfr...@snowman.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 *** a/doc/src/sgml/plpgsql.sgml --- b/doc/src/sgml/plpgsql.sgml *** *** 300,310 $$ LANGUAGE plpgsql; para 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 literalFOR/ loop ! iterating over a range of integer values is automatically declared as an ! integer variable, and likewise the loop variable of a literalFOR/ loop ! iterating over a cursor's result is automatically declared as a ! record variable.) /para para --- 300,308 para All variables used in a block must be declared in the declarations section of the block. ! (The only exceptions are the loop variables of literalFOR/ and ! literalFOREACH/ loops which are automatically declared as the ! appropriate variable type to match what to loop is over.) /para para *** *** 1359,1375 GET DIAGNOSTICS integer_var = ROW_COUNT; listitem para ! A commandFOR/ statement sets literalFOUND/literal true ! if it iterates one or more times, else false. This applies to ! all four variants of the commandFOR/ statement (integer ! commandFOR/ loops, record-set commandFOR/ loops, ! dynamic record-set commandFOR/ loops, and cursor ! commandFOR/ loops). ! literalFOUND/literal is set this way when the ! commandFOR/ loop exits; inside the execution of the loop, ! literalFOUND/literal is not modified by the ! commandFOR/ statement, although it might be changed by the ! execution of other statements within the loop body. /para /listitem listitem --- 1357,1375 listitem para ! A commandFOR/ or commandFOREACH/ statement sets ! literalFOUND/literal to true if it iterates one or more times, ! else to false. This applies to all four variants of the ! commandFOR/ statement (integer commandFOR/ loops, record-set ! commandFOR/ loops, dynamic record-set commandFOR/ loops, and ! cursor commandFOR/ loops) and all variants of the ! commandFOREACH/ statement (currently only ARRAY ! commandFOREACH/ loops). literalFOUND/literal is set this ! way when the commandFOR/ or commandFOREACH/ loop exits; ! inside the execution of the loop, literalFOUND/literal is not ! modified by the commandFOR/ or commandFOREACH/ statement, ! although it might be changed by the execution of other statements ! within the loop body. /para /listitem listitem *** *** 1910,1918 END CASE; para With the literalLOOP/, literalEXIT/, ! literalCONTINUE/, literalWHILE/, and literalFOR/ ! statements, you can arrange for your applicationPL/pgSQL/ ! function to repeat a series of commands. /para sect3 --- 1910,1918 para With the literalLOOP/, literalEXIT/, ! literalCONTINUE/, literalWHILE/, literalFOR/, ! and literalFOREACH/ statements, you can arrange for your ! applicationPL/pgSQL/ function to repeat a series of commands. /para sect3 *** *** 2238,2243 END LOOP optional replaceablelabel/replaceable /optional; --- 2238,2285 /para /sect2 +sect2 id=plpgsql-array-foreach-loop + titleLooping Through Arrays/title + + para + Similar to a literalFOR/ loop is the literalFOREACH/ loop. + literalFOREACH/ is used to loop over multi-value variables, such + as ARRAYs. Other multi-value variables may be added to literalFOREACH/ + later. Note that literalFOREACH/ can be thought of horizantally + looping, whereas literalFOR/ can be thought of a vertical loop. + The literalFOREACH/ statement to loop over an
Re: [HACKERS] updated patch for foreach stmt
2011/2/8 Stephen Frost sfr...@snowman.net: 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 sfr...@snowman.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 sfr...@snowman.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 sfr...@snowman.net Date: Tue Feb 8 14:27:05 2011 -0500 PL/PgSQL FOREACH Minor Whitespace Cleanup commit 612cf5485f202a49aec70cf32f74d19d0d130b6b Author: Stephen Frost sfr...@snowman.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 sfr...@snowman.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- -- 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
2011/2/8 Stephen Frost sfr...@snowman.net: * 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 sfr...@snowman.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- -- 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 (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 sfr...@snowman.net Date: Tue Feb 8 16:15:03 2011 -0500 Add ARRAY keyword to example, ewps. commit 34a8ffd8d4cfe42bb4f698564f16bd468b9f2613 Author: Stephen Frost sfr...@snowman.net Date: Tue Feb 8 16:14:17 2011 -0500 Tabs are bad, mmmkay. commit cf1ebcb7e4905cc31cd58b4fd9fa90cd488cc0c0 Author: Stephen Frost sfr...@snowman.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 *** a/doc/src/sgml/plpgsql.sgml --- b/doc/src/sgml/plpgsql.sgml *** *** 300,310 $$ LANGUAGE plpgsql; para 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 literalFOR/ loop ! iterating over a range of integer values is automatically declared as an ! integer variable, and likewise the loop variable of a literalFOR/ loop ! iterating over a cursor's result is automatically declared as a ! record variable.) /para para --- 300,308 para All variables used in a block must be declared in the declarations section of the block. ! (The only exceptions are the loop variables of literalFOR/ and ! literalFOREACH/ loops which are automatically declared as the ! appropriate variable type to match what to loop is over.) /para para *** *** 1359,1375 GET DIAGNOSTICS integer_var = ROW_COUNT; listitem para ! A commandFOR/ statement sets literalFOUND/literal true ! if it iterates one or more times, else false. This applies to ! all four variants of the commandFOR/ statement (integer ! commandFOR/ loops, record-set commandFOR/ loops, ! dynamic record-set commandFOR/ loops, and cursor ! commandFOR/ loops). ! literalFOUND/literal is set this way when the ! commandFOR/ loop exits; inside the execution of the loop, ! literalFOUND/literal is not modified by the ! commandFOR/ statement, although it might be changed by the ! execution of other statements within the loop body. /para /listitem listitem --- 1357,1375 listitem para ! A commandFOR/ or commandFOREACH/ statement sets ! literalFOUND/literal to true if it iterates one or more times, ! else to false. This applies to all four variants of the ! commandFOR/ statement (integer commandFOR/ loops, record-set ! commandFOR/ loops, dynamic record-set commandFOR/ loops, and ! cursor commandFOR/ loops) and all variants of the ! commandFOREACH/ statement (currently only ARRAY ! commandFOREACH/ loops). literalFOUND/literal is set this ! way when the commandFOR/ or commandFOREACH/ loop exits; ! inside the execution of the loop, literalFOUND/literal is not ! modified by the commandFOR/ or commandFOREACH/ statement, ! although it might be changed by the execution of other statements ! within the loop body. /para /listitem listitem *** *** 1910,1918 END CASE; para With the literalLOOP/, literalEXIT/, ! literalCONTINUE/, literalWHILE/, and literalFOR/ ! statements, you can arrange for your applicationPL/pgSQL/ ! function to repeat a series of commands. /para sect3 --- 1910,1918 para With the literalLOOP/, literalEXIT/, ! literalCONTINUE/, literalWHILE/, literalFOR/, ! and literalFOREACH/ statements, you can arrange for your ! applicationPL/pgSQL/ function to repeat a series of commands. /para sect3 *** *** 2238,2243 END LOOP optional replaceablelabel/replaceable /optional; --- 2238,2287 /para /sect2 +sect2 id=plpgsql-array-foreach-loop + titleLooping Through Arrays/title + + para + Similar to a literalFOR/ loop is the literalFOREACH/ loop. + literalFOREACH/ is used to loop over multi-value variables, such + as ARRAYs. Other multi-value variables may be added to literalFOREACH/ + later. Note that literalFOREACH/ can be thought of horizantally + looping, whereas literalFOR/ can be thought of a vertical loop. + The literalFOREACH/ statement to loop over an ARRAY is: + + synopsis + optional
Re: [HACKERS] updated patch for foreach stmt
* 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
