Re: plpgsql and qualified variable names

"Affan Salman" <affan@enterprisedb.com> writes:
> Could we not, at least, support explicit column disambiguation?

The problem is that there are places in the SQL grammar where we don't
allow qualification of a SQL name --- INSERT column lists, UPDATE SET
targets, and SELECT AS labels are three I can think of offhand.
Without fixing that it's a bit tough, and in at least the UPDATE
case there are severe ambiguity problems if we try to allow a noise
qualification.

In at least those three cases, we know that it's not sensible to
substitute a parameter.  If that's true in all the problem cases,
which seems likely, then we could do something with Greg's idea
of using the raw parse tree from the main SQL parser to guide
decisions about where parameters may be substituted.  I complained
earlier about the loss of a printable representation of the
substituted query, but we'd not necessarily have to give that up.
Seeing that ColumnRef carries a pointer back into the source text,
we could use the ColumnRefs to drive a textual substitution and
not have to change that aspect of the API.
        regards, tom lane