Hello 2009/3/7 Tom Lane <t...@sss.pgh.pa.us>: > Gregory Stark <st...@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 > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers