... BTW, I thought of a consideration that we probably need some
answer for. As far as I can see, the patch assigns NodeTag values
sequentially in the order it sees the struct declarations in the
input files; an order that doesn't have a lot to do with our past
practice. The problem with that is that it's next door to impossible
to control the tag value assigned to any one struct. During normal
development that's not a big deal, but what if we need to add a
node struct in a released branch? As nodes.h observes already,
* Note that inserting or deleting node types changes the numbers of other
* node types later in the list. This is no problem during development, since
* the node numbers are never stored on disk. But don't do it in a released
* branch, because that would represent an ABI break for extensions.
We used to have the option of sticking new nodetags at the end of
the list in this situation, but we won't anymore.
It might be enough to invent a struct-level attribute allowing
manual assignment of node tags, ie
typedef struct MyNewNode pg_node_attr(nodetag=466)
where it'd be the programmer's responsibility to pick a nonconflicting
tag number. We'd only ever use that in ABI-frozen branches, so
manual assignment of the tag value should be workable.
Anyway, this isn't something we have to have before committing,
but I think we're going to need it at some point.
regards, tom lane