From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Drouvot, Bertrand" <bdrouvot(at)amazon(dot)com> |
Subject: | Re: Generating code for query jumbling through gen_node_support.pl |
Date: | 2023-02-10 21:40:08 |
Message-ID: | 413164.1676065208@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:
> Okay, understood. Following this string of thoughts, I am a bit
> surprised for two cases, though:
> - PartitionPruneStep.
> - Plan.
> Both are abstract and both are marked with no_equal. I guess that
> applying no_query_jumble to both of them is fine, and that's what you
> mean?
On second thought, the point of that is to allow the no_equal property
to automatically inherit to child node types, so doing likewise
for no_query_jumble is sensible.
>> The changes in parsenodes.h seem wrong, except for RawStmt. Those node
>> types are used in parsed queries, aren't they?
> RTEPermissionInfo is a recent addition, as of a61b1f7. This commit
> documents it as a plan node, still it is part of a Query while being
> ignored in the query jumbling since its introduction, so I am a bit
> confused by this one.
Hmm ... it is part of Query, so that documentation is wrong, and the
fact that it's not reached by query jumbling kind of seems like a bug.
However, it might be that everything in it is derived from something
else that *is* covered by jumbling, in which case that's okay, if
underdocumented.
> ... Peter E. has
> mentioned upthread that a few nodes should include more jumbling while
> some other parts should be ignored. This should be analyzed
> separately because ~15 does not seem to be strictly right, either.
Yeah. It'd surprise me not at all if people have overlooked that.
v2 looks good to me as far as it goes. I agree these other questions
deserve a separate look.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-02-10 21:46:19 | Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry |
Previous Message | Andres Freund | 2023-02-10 21:34:29 | Re: Rework LogicalOutputPluginWriterUpdateProgress |