public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Peter Eisentraut <[email protected]>
Cc: David Rowley <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: automatically generating node support functions
Date: Tue, 05 Jul 2022 20:54:46 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAApHDvppoxUxzRJbwF9oOF12ngdfNoPEMfDsu63+LREgGnheUw@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

... 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

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]
  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