Re: Out parameters handling

Hello

2009/3/7 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> I'm not sure that's any better. The case where I've run into this is when I
>> have something like:
>>  balance := new value
>>  UPDATE tab SET balance = balance
>> In that case the only way we could get it right is if we default to the local
>> variable but only in contexts where an expression is valid.
>
> AFAICS getting that "right" would require the parser to develop advanced
> mind reading capabilities.  We could probably fix it to know that the
> first "balance" must be a table column name, but there is no principled
> way to make a choice about the second one; and you could easily invent
> slightly different scenarios where resolving it as the column name is
> the right thing.
>
> Anyway, I'm unsure whether this is related to the complaints upthread,
> which is why I was asking.
>
>                        regards, tom lane

I thing, we mainly need detection of this situation. It is same as
detection of ambiguous column names in SQL. PL/pgSQL has enough tools
for solving - main problem is in detection. After detection of some
possible conflict we should to raise exception or warning (controlled
by GUC).

regards
Pavel Stehule

>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>