On Sat, Mar 4, 2017 at 1:52 PM, Peter Geoghegan <p...@bowt.ie> wrote: > 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.
Lukas evidently thinks otherwise, based on the original post. > 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. Well, Lukas's original suggestion of using $n for a placeholder would do that, unless there's already a $n with the same numerical value, but Andres's proposal to use $-n or $:n would not. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
