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

On 24.03.22 22:57, David Rowley wrote:
>   * Unknown attributes are ignored.  Some additional attributes are used for
>   * special "hack" cases.
> 
> I think these really should all be documented.  If someone needs to
> use one of these hacks then they're going to need to trawl through
> Perl code to see if you've implemented something that matches the
> requirements.  I'd personally rather not have to look at the Perl code
> to find out which attributes I need to use for my new field. I'd bet
> I'm not the only one.

The only such hacks are the three path_hack[1-3] cases that correspond 
to the current _outPathInfo().  I've been thinking long and hard about 
how to generalize any of these but couldn't come up with much yet.  I 
suppose we could replace the names "path_hackN" with something more 
descriptive like "reloptinfo_light" and document those in nodes.h, which 
might address your concern on paper.  But I think you'd still need to 
understand all of that by looking at the definition of Path and its 
uses, so documenting those in nodes.h wouldn't really help, I think. 
Other ideas welcome.

> 2. Some of these comment lines have become pretty long after having
> added the attribute macro.
> 
> e.g.
> 
> PlannerInfo *subroot pg_node_attr(readwrite_ignore); /* modified
> "root" for planning the subquery;
>     not printed, too large, not interesting enough */
> 
> I wonder if you'd be better to add a blank line above, then put the
> comment on its own line, i.e:
> 
>   /* modified "root" for planning the subquery; not printed, too large,
> not interesting enough */
> PlannerInfo *subroot pg_node_attr(readwrite_ignore);

Yes, my idea was to make a separate patch first that reformats many of 
the structs and comments in that way.

> 3. My biggest concern with this patch is it introducing some change in
> behaviour with node copy/equal/read/write.  I spent some time in my
> diff tool comparing the files the Perl script built to the existing
> code.  Unfortunately, that job is pretty hard due to various order
> changes in the outputted functions.  I wonder if it's worth making a
> pass in master and changing the function order to match what the
> script outputs so that a proper comparison can be done just before
> committing the patch.

Just reordering won't really help.  The content of the functions will be 
different, for example because nodes that include Path will include its 
fields inline instead of calling out to _outPathInfo().

IMO, the confirmation that it works is in COPY_PARSE_PLAN_TREES etc.

> The problem I see is that master is currently
> a very fast-moving target and a detailed comparison would be much
> easier to do if the functions were in the same order. I'd be a bit
> worried that someone might commit something that requires some special
> behaviour and that commit goes in sometime between when you've done a
> detailed and when you commit the full patch.

> Also, I'm quite keen to see this work make it into v15.  Do you think
> you'll get time to do that? Thanks for working on it.

My thinking right now is to wait for the PG16 branch to open and then 
consider putting it in early.  That would avoid creating massive 
conflicts with concurrent patches that change node types, and it would 
also relax some concerns about undiscovered behavior changes.

If there is interest in getting it into PG15, I do have capacity to work 
on it.  But in my estimation, this feature is more useful for future 
development, so squeezing in just before feature freeze wouldn't provide 
additional benefit.