Horton

Re: automatically generating node support functions

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Andres Freund <andres@anarazel.de>, David Rowley <dgrowleyml@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-07-11T17:57:38Z
Lists: pgsql-hackers 
I wrote:
>> Andres Freund <andres@anarazel.de> writes:
>>> I was just rebasing meson ontop of this and was wondering whether the input
>>> filenames were in a particular order:

Pushed a patch to make that a bit less random-looking.

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

I had second thoughts about that, after noticing that alphabetizing
the NodeTag enum increased the backend's size by 20K or so.  Presumably
that's telling us that a bunch of switch statements got less dense,
which might possibly cause performance issues thanks to poorer cache
behavior or the like.  Maybe it's still appropriate to do, but it's
not as open-and-shut as I first thought.

More generally, I'm having second thoughts about the wisdom of
auto-generating the NodeTag enum at all.  With the current setup,
I am absolutely petrified about the risk of silent ABI breakage
thanks to the enum order changing.  In particular, if the meson
build fails to use the same input-file order as the makefile build,
then we will get different enum orders from the two builds, causing
an ABI discrepancy that nobody would notice until we had catastrophic
extension-compatibility issues in the field.

Of course, sorting the tags by name is a simple way to fix that.
But I'm not sure I want to buy into being forced to do it like that,
because of the switch-density question.

So at this point I'm rather attracted to the idea of reverting to
a manually-maintained NodeTag enum.  We know how to avoid ABI
breakage with that, and it's not exactly the most painful part
of adding a new node type.  Plus, that'd remove (most of?) the
need for gen_node_support.pl to deal with "node-tag-only" structs
at all.

Thoughts?

			regards, tom lane

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