Hello
2009/3/7 Tom Lane <tgl@sss.pgh.pa.us>:
> Gregory Stark <stark@enterprisedb.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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
