Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Mar 1, 2017 at 8:21 PM, Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> wrote:
>> On 2/28/17 20:01, Lukas Fittl wrote:
>>> I'd like to propose changing the replacement character from ? to instead
>>> be a parameter (like $1).
>> Hmm, I think this could confuse people into thinking that the queries
>> displayed were in fact prepared queries.
> Perhaps there could be a choice of behaviors. Even if we all agreed
> that parameter notation was better in theory, there's something to be
> said for maintaining backward compatibility, or having an option to do
> so.
Meh ... we've generally regretted it when we "solved" a backwards
compatibility problem by introducing a GUC that changes query semantics.
I'm inclined to think we should either do it or not.
My own vote would probably be for "not", because I haven't seen a case
made why it's important to be able to automatically distinguish a
constant-substitution marker from a "?" operator.
On the other hand, it seems like arguing for backwards compatibility here
is a bit contradictory, because that would only matter if you think there
*are* people trying to automatically parse the output of
pg_stat_statements in that much detail. And if there are, they would
likely appreciate it becoming less ambiguous.
But speaking of ambiguity: isn't it possible for $n symbols to appear in
pg_stat_statements already? I think it is, both from extended-protocol
client queries and from SPI commands, which would mean that the proposal
as it stands is not fixing the ambiguity problem at all. So yes, we need
another idea.
regards, tom lane