Re: Query Jumbling for CALL and SET utility statements
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: "Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>,
Fujii Masao <masao.fujii@oss.nttdata.com>,
Julien Rouhaud <rjuju123@gmail.com>,
Jeremy Schneider <schnjere@amazon.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Pavel Stehule <pavel.stehule@gmail.com>,
Andres Freund <andres@anarazel.de>,
"Imseih (AWS),
Sami" <simseih@amazon.com>
Date: 2022-10-07T03:51:52Z
Lists: pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes: > While studying a bit more this thread, I've been reminded of the fact > that this would treat different flavors of BEGIN/COMMIT commands (mix > of upper/lower characters, etc.) as different entries in > pg_stat_statements, and it feels inconsistent to me that we'd begin > jumbling the 2PC and savepoint commands with their nodes but not do > that for the rest of the commands, even if, as mentioned upthread, > applications may not mix grammars. I've been thinking since the beginning of this thread that there was no coherent, defensible rationale being offered for jumbling some utility statements and not others. I wonder if the answer is to jumble them all. We avoided that up to now because it would imply a ton of manual effort and future code maintenance ... but now that the backend/nodes/ infrastructure is largely auto-generated, could we auto-generate the jumbling code? regards, tom lane
Commits
-
Show values of SET statements as constants in pg_stat_statements
- dc68515968e8 18.0 landed
-
Teach contrib/pg_stat_statements to handle multi-statement commands better.
- 83f2061dd037 10.0 cited