Re: automating RangeTblEntry node support

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Paul Jungwirth <pj(at)illuminatedcomputing(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: automating RangeTblEntry node support
Date: 2024-02-20 07:57:25
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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()

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2024-02-20 08:02:36 Re: logical decoding and replication of sequences, take 2
Previous Message Fabrice Chapuis 2024-02-20 07:47:52 pg_restore option --clean