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
