On Fri, Nov 29, 2019 at 7:21 AM Michael Paquier <mich...@paquier.xyz> wrote: > > On Fri, Nov 29, 2019 at 03:19:49PM +0900, Michael Paquier wrote: > > On Wed, Nov 13, 2019 at 12:53:09PM +0100, Julien Rouhaud wrote: > >> I'd really like to have the queryid function available through SQL, > >> but I think that this specific case wouldn't work very well for > >> pg_stat_statements' approach as it's working with oid. The query > >> string in pg_stat_activity is the user provided one rather than a > >> fully-qualified version, so in order to get that query's queryid, you > >> need to know the exact search_path in use in that backend, and that's > >> not something available. > > > > Yeah.. So, we have a patch marked as ready for committer here, and it > > seems to me that we have a couple of issues to discuss more about > > first particularly this query ID of 0. Again, do others have more > > any input to offer?
I just realized that with current infrastructure it's not possible to display a utility queryid. We need to recognize utility to not process the counters twice (once in processUtility, once in the underlying executor), so we don't provide a queryid for utility statements in parse analysis. Current magic value 0 has the side effect of showing an invalid queryid for all utilty statements, and using a magic value different from 0 will just always display that magic value. We could instead add another field in the Query and PlannedStmt structs, say "int queryid_flags", that extensions could use for their needs? > And while on it, the latest patch does not apply, so a rebase is > needed here. Yep, I noticed that this morning. I already rebased the patch locally, I'll send a new version with new modifications when we reach an agreement on the utility issue.