Re: automatically generating node support functions

On 14.02.22 18:09, Tom Lane wrote:
> * It's time for action on the business about extracting comments
> from the to-be-deleted code.

done

> * The Perl script is kind of under-commented for my taste.
> It lacks a copyright notice, too.

done

> * In the same vein, I should not have to reverse-engineer what
> the available pg_node_attr() properties are or do.  Perhaps they
> could be documented in the comment for the pg_node_attr macro
> in nodes.h.

done

> * Maybe the generated file names could be chosen less opaquely,
> say ".funcs" and ".switch" instead of ".inc1" and ".inc2".

done

> * I don't understand why there are changes in the #include
> lists in copyfuncs.c etc?

Those are #include lines required for the definitions of various 
structs.  Since the generation script already knows which header files 
are relevant (they are its input files), it can just generate the 
required #include lines as well.  That way, the remaining copyfuncs.c 
only has #include lines for things that the (remaining) file itself 
needs, not what the files included by it need, and if a new header file 
were to be added, it doesn't have to be added in 4+ places.

> * I think that more thought needs to be put into the format
> of the *nodes.h struct declarations, because I fear pgindent
> is going to make a hash of what you've done here.  When we
> did similar stuff in the catalog headers, I think we ended
> up moving a lot of end-of-line comments onto their own lines.

I have tested pgindent repeatedly throughout this project, and it 
doesn't look too bad.  You are right that some manual curation of 
comment formatting would be sensible, but I think that might be better 
done as a separate patch.

> * I assume the pg_config_manual.h changes are not meant for
> commit?

right