Re: automatically generating node support functions - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: automatically generating node support functions
Date
Msg-id fcad8d71c44f6dd00fb50d052f1391a6a0bf1347.camel@vmware.com
Whole thread Raw
In response to Re: automatically generating node support functions  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: automatically generating node support functions
List pgsql-hackers
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

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: SQL/JSON: JSON_TABLE
Next
From: Paul Martinez
Date:
Subject: Re: [PATCH] Partial foreign key updates in referential integrity triggers