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 11:37:39 -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]>

Peter Eisentraut <[email protected]> writes:
> On 11.07.22 01:09, Tom Lane 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:

> 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

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