public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Peter Eisentraut <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: David Rowley <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: automatically generating node support functions
Date: Mon, 11 Jul 2022 13:57:38 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<b9acf63c-6693-d87c-f010-ca8ad502a39f@enterp! risedb.com>
	<[email protected]>
	<611d2e! [email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

I wrote:
>> Andres Freund <[email protected]> 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

view thread (80+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: automatically generating node support functions
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox