| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Jeremy Schneider <schnjere(at)amazon(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, "Imseih (AWS), Sami" <simseih(at)amazon(dot)com> |
| Subject: | Re: Query Jumbling for CALL and SET utility statements |
| Date: | 2022-10-07 03:51:52 |
| Message-ID: | 3088762.1665114712@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2022-10-07 03:51:55 | Re: shadow variables - pg15 edition |
| Previous Message | Michael Paquier | 2022-10-07 03:41:13 | Re: Query Jumbling for CALL and SET utility statements |