Horton

Re: automatically generating node support functions

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

View thread View on postgr.es
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-03-25T13:08:32Z
Lists: 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.

Commits

  1. Fix MSVC build script's check for obsolete node support functions.

  2. Improve performance of ORDER BY / DISTINCT aggregates

  3. doc: Fix typos in protocol.sgml

  4. Tighten up parsing logic in gen_node_support.pl.

  5. Add defenses against unexpected changes in the NodeTag enum list.

  6. Add copy/equal support for XID lists

  7. Rationalize order of input files for gen_node_support.pl.

  8. Make assorted quality-of-life improvements in gen_node_support.pl.

  9. Doc: rearrange high-level commentary about node support coverage.

  10. Automatically generate node support functions

  11. Adjust node serialization tag of A_Expr for consistency

  12. Remove T_Join and T_Plan

  13. Reformat some more node comments

  14. Reformat some node comments

  15. Remove JsonPathSpec typedef

  16. Add missing enum tag in enum used in nodes

  17. Add Cardinality typedef

  18. Make node output prefix match node structure name

  19. Add WRITE_INDEX_ARRAY

  20. Add COPY_ARRAY_FIELD and COMPARE_ARRAY_FIELD

  21. Remove T_Expr

  22. Change NestPath node to contain JoinPath node

  23. Change SeqScan node to contain Scan node

  24. Check the size in COPY_POINTER_FIELD

  25. Remove T_MemoryContext

  26. Add missing enum tags in enums used in nodes

  27. Rename some node support functions for consistency

  28. Rename argument of _outValue()

  29. Rename NodeTag of ExprState