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