Re: Query Jumbling for CALL and SET utility statements

Hi,

On 10/7/22 6:13 AM, Michael Paquier wrote:
> On Thu, Oct 06, 2022 at 11:51:52PM -0400, Tom Lane wrote:
>> 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.
>
> Yeah. The potential performance impact of all the TransactionStmts
> worries me a bit, though.
>
>> 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?

I think that's a good idea.

>
> Probably. One part that may be tricky though is the location of the
> constants we'd like to make generic, but perhaps this could be handled
> by using a dedicated variable type that just maps to int?

It looks to me that we'd also need to teach the perl parser which fields
per statements struct need to be jumbled (or more probably which ones to
exclude from the jumbling, for example funccall in CallStmt). Not sure
yet how to teach the perl parser, but I'll build this list first to help
decide for a right approach, unless you already have some thoughts about it?

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com