>
> 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.
>
Variables substitution is probable them most big hack on plpgsql. I am
not sure, so this is well solution. We can generate more helpful hint
and that is all.
Regards
Pavel Stehule