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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
