On Sat, Mar 4, 2017 at 8:02 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
