Re: Proposal: plpgsql - "for in array" statement

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: plpgsql - "for in array" statement
Date: 2010-09-28 20:39:19
Message-ID: AANLkTikCGGi2yNZUr8260UJmFEozpLDBk1=j1ZGEaAjX@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2010/9/28 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> 2010/9/28 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>> As an example, is this a for-in-query or a
>>> for-in-array?
>>>
>>>        FOR v IN (SELECT arraycol FROM tab) LOOP ...
>
>> This is a subquery - so it is a for-in-array - should return one row
>> with one column.
>
> That's not obvious at all.  It's legal right now to write that, and it
> will be interpreted as for-in-query.

but it has not a sense. It's based on implementation and I am sure, so
this isn't documented. Yes, we are able to write

a := 10 FROM tab WHERE y = 10

but it is just more bug then required feature.

FOR v IN (SELECT FROM) when select returns more than one row is big
inconsistency - and this is bug, when this is allowed

Regards

Pavel

 Furthermore, there are cases where
> it's essential to be able to write a left paren before SELECT, so that
> you can control the precedence of UNION/INTERSECT/EXCEPT constructs.
> So you're proposing to remove functionality and break existing code in
> order to have a "simple" syntax for for-in-array.
>
>                        regards, tom lane
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2010-09-28 20:41:19 Re: Proposal: plpgsql - "for in array" statement
Previous Message Tom Lane 2010-09-28 20:37:57 Re: Proposal: plpgsql - "for in array" statement