From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
        Andres Freund <andres@anarazel.de>,
        David Rowley <dgrowleyml@gmail.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: automatically generating node support functions
In-reply-to: 
 <CA+TgmoagVZJdt-pyNw-UK_YzrrFPGtT4oQ1LtbCeCSuAk8y0UQ@mail.gmail.com>
References: <1294462.1656875649@sss.pgh.pa.us>
 <57df9f30-d2cf-9126-28d4-ae40a2e733a9@enterprisedb.com>
 <1593978.1656953960@sss.pgh.pa.us>
 <b53b92e0-1153-a31a-8c52-157fa2e07771@enterprisedb.com>
 <2592455.1657140387@sss.pgh.pa.us> <3302658.1657288366@sss.pgh.pa.us>
 <3488143.1657310625@sss.pgh.pa.us>
 <11148777-fbe2-5188-195d-48f5083573c5@enterprisedb.com>
 <20220710214622.haiektrjzisob6rl@awork3.anarazel.de>
 <815831.1657494597@sss.pgh.pa.us>
 <45f508cb-e30b-c252-e081-4548deafa34c@enterprisedb.com>
 <1116889.1657553859@sss.pgh.pa.us> <1201553.1657562258@sss.pgh.pa.us>
 <CA+TgmoagVZJdt-pyNw-UK_YzrrFPGtT4oQ1LtbCeCSuAk8y0UQ@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Mon, 11 Jul 2022 14:17:44 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1229445.1657569262.1@sss.pgh.pa.us>
Date: Mon, 11 Jul 2022 15:54:22 -0400
Message-ID: <1229446.1657569262@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1229446.1657569262%40sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jul 11, 2022 at 1:57 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

> I think this is a valid concern, but having it be automatically
> generated is awfully handy, so I think it would be nice to find some
> way of preserving that.

Agreed.  The fundamental problem seems to be that each build toolchain
has its own source of truth about the file processing order, but we now
see that there had better be only one.  We could make the sole source
of truth about that be gen_node_support.pl itself, I think.

We can't simply move the file list into gen_node_support.pl, because
(a) the build system has to know about the dependencies involved, and
(b) gen_node_support.pl wouldn't know what to do in VPATH situations.
However, we could have gen_node_support.pl contain a canonical list
of the files it expects to be handed, and make it bitch if its
arguments don't match that.

That's ugly I admit, but the set of files of interest doesn't change
so often that maintaining one additional copy would be a big problem.

Anybody got a better idea?

			regards, tom lane