Thread
-
updated patch for foreach stmt
Pavel Stehule <pavel.stehule@gmail.com> — 2011-01-30T19:28:41Z
Hello I resend a patch with last update of this patch Regards Pavel Stehule
-
Re: updated patch for foreach stmt
Stephen Frost <sfrost@snowman.net> — 2011-02-08T20:26:24Z
Greetings, * Pavel Stehule (pavel.stehule@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 <sfrost@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 <sfrost@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 <sfrost@snowman.net> Date: Tue Feb 8 14:27:05 2011 -0500 PL/PgSQL FOREACH Minor Whitespace Cleanup commit 612cf5485f202a49aec70cf32f74d19d0d130b6b Author: Stephen Frost <sfrost@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 <sfrost@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 -
Re: updated patch for foreach stmt
Robert Haas <robertmhaas@gmail.com> — 2011-02-08T20:32:12Z
On Tue, Feb 8, 2011 at 3:26 PM, Stephen Frost <sfrost@snowman.net> wrote: > Greetings, > > * Pavel Stehule (pavel.stehule@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
-
Re: updated patch for foreach stmt
Pavel Stehule <pavel.stehule@gmail.com> — 2011-02-08T20:55:53Z
2011/2/8 Stephen Frost <sfrost@snowman.net>: > Greetings, > > * Pavel Stehule (pavel.stehule@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 <sfrost@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 <sfrost@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 <sfrost@snowman.net> > Date: Tue Feb 8 14:27:05 2011 -0500 > > PL/PgSQL FOREACH Minor Whitespace Cleanup > > commit 612cf5485f202a49aec70cf32f74d19d0d130b6b > Author: Stephen Frost <sfrost@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 <sfrost@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----- > >
-
Re: updated patch for foreach stmt
Stephen Frost <sfrost@snowman.net> — 2011-02-08T21:00:05Z
* Robert Haas (robertmhaas@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 <sfrost@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 -
Re: updated patch for foreach stmt
Pavel Stehule <pavel.stehule@gmail.com> — 2011-02-08T21:04:51Z
2011/2/8 Stephen Frost <sfrost@snowman.net>: > * Robert Haas (robertmhaas@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 <sfrost@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----- > >
-
Re: updated patch for foreach stmt
Stephen Frost <sfrost@snowman.net> — 2011-02-08T21:16:16Z
* Pavel Stehule (pavel.stehule@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 <sfrost@snowman.net> Date: Tue Feb 8 16:15:03 2011 -0500 Add ARRAY keyword to example, ewps. commit 34a8ffd8d4cfe42bb4f698564f16bd468b9f2613 Author: Stephen Frost <sfrost@snowman.net> Date: Tue Feb 8 16:14:17 2011 -0500 Tabs are bad, mmmkay. commit cf1ebcb7e4905cc31cd58b4fd9fa90cd488cc0c0 Author: Stephen Frost <sfrost@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 -
Re: updated patch for foreach stmt
Stephen Frost <sfrost@snowman.net> — 2011-02-08T21:52:55Z
* Robert Haas (robertmhaas@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
-
Re: updated patch for foreach stmt
Tom Lane <tgl@sss.pgh.pa.us> — 2011-02-16T01:44:51Z
Robert Haas <robertmhaas@gmail.com> writes: > On Tue, Feb 8, 2011 at 3:26 PM, Stephen Frost <sfrost@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
-
Re: updated patch for foreach stmt
Robert Haas <robertmhaas@gmail.com> — 2011-02-16T01:59:18Z
On Tue, Feb 15, 2011 at 8:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Tue, Feb 8, 2011 at 3:26 PM, Stephen Frost <sfrost@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
-
Re: updated patch for foreach stmt
Stephen Frost <sfrost@snowman.net> — 2011-02-16T02:20:43Z
* Robert Haas (robertmhaas@gmail.com) wrote: > On Tue, Feb 15, 2011 at 8:44 PM, Tom Lane <tgl@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
-
Re: updated patch for foreach stmt
Andrew Dunstan <andrew@dunslane.net> — 2011-02-16T03:10:18Z
On 02/15/2011 08:59 PM, Robert Haas wrote: > On Tue, Feb 15, 2011 at 8:44 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote: >> Robert Haas<robertmhaas@gmail.com> writes: >>> On Tue, Feb 8, 2011 at 3:26 PM, Stephen Frost<sfrost@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 -
Re: updated patch for foreach stmt
Tom Lane <tgl@sss.pgh.pa.us> — 2011-02-16T04:29:39Z
Andrew Dunstan <andrew@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
-
Re: updated patch for foreach stmt
Pavel Stehule <pavel.stehule@gmail.com> — 2011-02-16T04:45:19Z
2011/2/16 Tom Lane <tgl@sss.pgh.pa.us>: > Andrew Dunstan <andrew@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 >
-
Re: updated patch for foreach stmt
Tom Lane <tgl@sss.pgh.pa.us> — 2011-02-16T06:55:30Z
Stephen Frost <sfrost@snowman.net> writes: > * Pavel Stehule (pavel.stehule@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