On Sat, 2007-07-14 at 19:52 -0400, Tom Lane wrote:
> "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.
Well, I think we need this, eventually.
It's just weird to have pseudo random failures in CREATE FUNCTION
because the naming of function developers happens to coincide with the
naming of DBAs.
BTW, much clearer docs, thanks.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com