Re: REVIEW: WIP: plpgsql - foreach in - Mailing list pgsql-hackers

From Tom Lane
Subject Re: REVIEW: WIP: plpgsql - foreach in
Date
Msg-id 13387.1296325456@sss.pgh.pa.us
Whole thread Raw
In response to Re: REVIEW: WIP: plpgsql - foreach in  (Stephen Frost <sfrost@snowman.net>)
Responses Re: REVIEW: WIP: plpgsql - foreach in  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> * Pavel Stehule (pavel.stehule@gmail.com) wrote:
>> You have a similar opinion like me about design this statement. But
>> there are others with strong negative opinion. For someone ARRAY ARRAY
>> should be a problem. So FOREACH is third way - more, it increase a
>> possibility for enhancing plpgsql in future.

> I look forward to hearing from the silent majority on this then.

Well, I haven't been exactly silent, but I was one of the people telling
Pavel not to use FOR in the first place.  The trouble is that we've
already overloaded FOR to within an inch of its life.  Adding yet
another potential syntax to follow FOR ... IN ... is just a bad idea,
especially since Pavel has evidently got ambitions to add yet more
nonstandard hac^H^H^Hfeatures here.

I have to agree that FOREACH is pretty ugly too, but I do *not* want to
use a syntax that can so easily be confused with the existing types of
for-loops.  We'd pay a significant price in the ability to issue syntax
error messages that were actually relevant to what the user thought he
was doing, for example.

See also
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01579.php
which tries to draw a clear distinction between what FOR does and what
FOREACH does.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Snapshots no longer build
Next
From: Peter Eisentraut
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Get rid of the global variable holding the error state