Re: automatically generating node support functions

On Tue, 2021-08-17 at 16:36 +0200, Peter Eisentraut wrote:
> Here is another set of preparatory patches that clean up various special
> cases and similar in the node support.
>
> 0001-Remove-T_Expr.patch
>
> Removes unneeded T_Expr.
>
> 0002-Add-COPY_ARRAY_FIELD-and-COMPARE_ARRAY_FIELD.patch
> 0003-Add-WRITE_INDEX_ARRAY.patch
>
> These add macros to handle a few cases that were previously hand-coded.

These look sane to me.

> 0004-Make-node-output-prefix-match-node-structure-name.patch
>
> Some nodes' output/read functions use a label that is slightly different
> from their node name, e.g., "NOTIFY" instead of "NOTIFYSTMT". This
> cleans that up so that an automated approach doesn't have to deal with
> these special cases.

Is there any concern about the added serialization length, or is that
trivial in practice? The one that particularly caught my eye is
RANGETBLENTRY, which was previously RTE. But I'm not very well-versed
in all the places these strings can be generated and stored.

> 0005-Add-Cardinality-typedef.patch
>
> Adds a typedef Cardinality for double fields that store an estimated row
> or other count. Works alongside Cost and Selectivity.

Should RangeTblEntry.enrtuples also be a Cardinality?

--Jacob