Re: automating RangeTblEntry node support

On 18.02.24 00:06, Matthias van de Meent wrote:
> I'm not sure that the cleanup which is done when changing a RTE's
> rtekind is also complete enough for this purpose.
> Things like inline_cte_walker change the node->rtekind, which could
> leave residual junk data in fields that are currently dropped during
> serialization (as the rtekind specifically ignores those fields), but
> which would add overhead when the default omission is expected to
> handle these fields; as they could then contain junk. It looks like
> there is some care about zeroing now unused fields, but I haven't
> checked that it covers all cases and fields to the extent required so
> that removing this specialized serializer would have zero impact on
> size once the default omission patch is committed.
>
> An additional patch with a single function that for this purpose
> clears junk fields from RTEs that changed kind would be appreciated:
> it is often hand-coded at those locations the kind changes, but that's
> more sensitive to programmer error.

Yes, interesting idea. Or maybe an assert-like function that checks an
existing structure for consistency. Or maybe both. I'll try this out.

In the meantime, if there are no remaining concerns, I propose to commit
the first two patches

Remove custom Constraint node read/write implementations
Remove custom _jumbleRangeTblEntry()