On Sat, Mar 4, 2017 at 8:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.
In my opinion, we expose query id (and dbid, and userid) as the
canonical identifier for each pg_stat_statements entry, and have done
so for some time. That's the stable API -- not query text. I'm aware
of cases where query text was used as an identifier, but that ended up
being hashed anyway.
Query text is just for human consumption. I'd be in favor of a change
that makes it easier to copy and paste a query, to run EXPLAIN and so
on. Lukas probably realizes that there are no guarantees that the
query text that appears in pg_stat_statements will even appear as
normalized in all cases. The "sticky entry" stuff is intended to
maximize the chances of that happening, but it's still generally quite
possible (e.g. pg_stat_statements never swaps constants in a query
like "SELECT 5, pg_stat_statements_reset()"). This means that we
cannot really say that this buys us a machine-readable query text
format, at least not without adding some fairly messy caveats.
--
Peter Geoghegan
