Re: Query Jumbling for CALL and SET utility statements

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(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 04:18:26
Message-ID: 20221007041826.56odjh3rf56dzfxx@jrouhaud
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 06, 2022 at 11:51:52PM -0400, Tom Lane wrote:
> 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.

Only a very small subset causes trouble in real life scenario, but I agree that
cherry-picking some utility statements isn't a great approach.

> 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?

That's a good idea. Naively, it seems doable as the infrastructure in
gen_node_support.pl already supports everything that should be needed (like
per-member annotation).

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2022-10-07 04:25:42 Re: ExecRTCheckPerms() and many prunable partitions
Previous Message Michael Paquier 2022-10-07 04:13:05 Re: Query Jumbling for CALL and SET utility statements