Re: final patch - plpgsql: for-in-array

Hello

2010/11/24 Tom Lane <tgl@sss.pgh.pa.us>:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Right, that was my impression, too.  But, I think this may be partly a
>> case of people talking past each other.  My impression of this
>> conversation was a repetition of this sequence:
>
>> A: This syntax is bad.
>> B: But it's way faster!
>
>> ...which makes no sense.  However, what I now think is going on here
>> is that there are really two separate things that are wished for here
>> - a more compact syntax, and a performance improvement.  And taken
>> separately, I agree with both of those desires.  PL/pgsql is an
>> incredibly clunky language syntactically, and it's also slow.  A patch
>> that improves either one of those things has value, whether or not it
>> also does the other one.
>
> I understand the desire for nicer syntax, in the abstract.  I'm just
> unimpressed by this particular change, mainly because I'm afraid that
> it will make syntax-error behaviors worse and foreclose future options
> for other changes to FOR.  If it were necessary to change the syntax
> to get the performance benefit, I might think that on balance we should
> do so; but it isn't.
>

I am for any readable syntax. It must not be FOR-IN-ARRAY. I
understand to problem with syntax-error checking. But I am not sure if
some >>different<< loop with control variable can be less ugliness in
language. Cannot we rewrite a parsing "for-clause" be more robust? I
agree with you, so there can be a other request in future. And if I
remember well, there was only few changes in other statements (on
parser level) and significant changes in FOR.

probably some hypothetical statement should be (my opinion)

FOR var [, vars]
<<UNKNOWN SYNTAX>>
LOOP ...
END LOOP;

PL/SQL uses a enhanced FOR

FOR var IN collection.first .. collection.last
LOOP
END LOOP;

From my view a introduction of new keyword should be a higher risk so
I don't would to do.

Regards

Pavel Stehule



>                        regards, tom lane
>