Re: automating RangeTblEntry node support

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: automating RangeTblEntry node support
Дата
Msg-id 4abe33b6-2a83-4bc0-8733-11b7308f36d0@eisentraut.org
обсуждение исходный текст
Ответ на Re: automating RangeTblEntry node support  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Ответы Re: automating RangeTblEntry node support  (Peter Eisentraut <peter@eisentraut.org>)
Список 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()




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fabrice Chapuis
Дата:
Сообщение: pg_restore option --clean
Следующее
От: Dilip Kumar
Дата:
Сообщение: Re: logical decoding and replication of sequences, take 2