Re: automatically generating node support functions

Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> On 11.07.22 01:09, Tom Lane wrote:
>> Andres Freund <andres(at)anarazel(dot)de> writes:
> I was just rebasing meson ontop of this and was wondering whether the input
> filenames were in a particular order:

> First, things used by later files need to be found in earlier files. So
> that constrains the order a bit.

Yeah, the script needs to see supertype nodes before subtype nodes,
else it will not realize that the subtypes are nodes at all. However,
there is not very much cross-header-file subtyping. I experimented with
rearranging the input-file order, and found that the *only* thing that
breaks it is to put primnodes.h after pathnodes.h (which fails because
PlaceHolderVar is a subtype of Expr). You don't even need nodes.h to be
first, which astonished me initially, but then I realized that both
NodeTag and struct Node are special-cased in gen_node_support.pl,
so we know enough to get by even before reading nodes.h.

More generally, the main *nodes.h files themselves are arranged in
pipeline order, eg parsenodes.h #includes primnodes.h. So that seems
to be a pretty safe thing to rely on even if we grow more cross-header
subtyping cases later. But I'd vote for putting the incidental files
in alphabetical order.

> Second, the order of the files determines the ordering of the output.
> The current order of the files reflects approximately the order how the
> manual code was arranged. That could be changed. We could also just
> sort the node types in the script and dump out everything alphabetically.

+1 for sorting alphabetically. I experimented with that and it's a
really trivial change.

regards, tom lane