I wrote:
> ... 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.
BTW, I looked into this a bit and found that it doesn't seem to be a
simple change. Basically what we'd want to do is take out the current
behavior in which the plpgsql lexer knows anything about which
identifiers are plpgsql variables, and have the substitutions happen
later, after we've run the collected statement or expression through
the main grammar. The problem is that doing so breaks the recognition
of plpgsql assignment statements, since the grammar currently keys off
the fact that the first token of the statement has been recognized to
match a variable name by the lexer. I'm not sure what's the most
reasonable way to fix that, but at the moment it looks like we're
talking about a pretty thoroughgoing redesign of the plpgsql lexer
and parser.
Anyway it seems like this whole area is a research project for 8.4
or later, not something we should try to fix now. But having said
that, there didn't seem to be any objection to the idea of changing
the outer block (where function parameters are declared) to be labeled
with the function name, instead of having no label as at present.
Does anyone think we should not do that for 8.3?
regards, tom lane
