public inbox for [email protected]  

help / color / mirror / Atom feed

From: Matthias van de Meent <[email protected]>
To: Paul Jungwirth <[email protected]>
Cc: [email protected]
Cc: Peter Eisentraut <[email protected]>
Subject: Re: automating RangeTblEntry node support
Date: Sun, 18 Feb 2024 00:06:19 +0100
Message-ID: <CAEze2WicmonS30rtPXT6aCR-huXXqr4Jgn64vu56Pt3=2J5frQ@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>

On Fri, 16 Feb 2024 at 21:36, Paul Jungwirth
<[email protected]> wrote:
>
> On 1/15/24 02:37, Peter Eisentraut wrote:
> > In this updated patch set, I have also added the treatment of the Constraint type.  (I also noted
> > that the manual read/write functions for the Constraint type are out-of-sync again, so simplifying
> > this would be really helpful.)  I have also added commit messages to each patch.
> >
> > The way I have re-ordered the patch series now, I think patches 0001 through 0003 are candidates for
> > inclusion after review, patch 0004 still needs a bit more analysis and testing, as described therein.
>
> Re bloating the serialization output, we could leave this last patch until after the work on that
> other thread is done to skip default-valued items.

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.

Kind regards,

Matthias van de Meent

view thread (3+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: automating RangeTblEntry node support
  In-Reply-To: <CAEze2WicmonS30rtPXT6aCR-huXXqr4Jgn64vu56Pt3=2J5frQ@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox