2010/12/17 Tom Lane <t...@sss.pgh.pa.us>: > Merlin Moncure <mmonc...@gmail.com> writes: >> On Fri, Dec 17, 2010 at 10:47 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> This seems like a really bad, confusing idea. I think it should throw >>> a type-mismatch error in this case. If there is any use-case for such a >>> thing, which I'm quite unconvinced of, it ought to use a separate syntax >>> rather than overloading the element-by-element syntax. > >> I don't agree at all -- iterating arrays by slice is a frequently >> requested feature (you can kinda sorta do it by slice notation, but >> arr[n] giving null is a -general FAQ. This is how people think arrays >> should work. I suppose that having this functionality reserved in a >> tiny corner of plpgsql is not so good, but I think foreach... would >> become the preferred way to iterate arrays always. > > Well, okay, if it's useful we can have it, but I still say it needs to > be a separate syntax. The example Pavel gives looks like nothing so > much as a beginner's error, ie putting [] on the target variable when > he shouldn't have.
Now the message is unclean - but it can be enhanced. We can a diagnose situation when result is multidimensional array and target isn't array, and the we can to throw user friendly message. > > Furthermore, it's underspecified: who's to say how many dimensions of > the array are supposed to get sliced off? There's no reasonable place > to extend this syntax to specify that. It will also be inconsistent > for "foreach scalar in array" to iterate element-by-element no matter > how many dimensions array has, while "foreach array in array" does > something different from that. > it reduce just one dimension. Now I expect, and I think so it is correct, so user knows a used dimension. Just doesn't know a data. So user can to decide and fill correct type. The design strictly remove any U.I. from design. So using a incorect type is bug. Because a FOREACH syntax is new, we can to enhance it to possible direction: FOREACH VALUE var IN ARRAY expr LOOP END LOOP and then it will iterate per one field without a dimension reduction. So this possibility is available and I think so could be implemented too. Pavel > 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
