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: Fri, 08 Jul 2022 09:52: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]>
	<CAApHDvppoxUxzRJbwF9oOF12ngdfNoPEMfDsu63+LREgGnheUw@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<b9acf63c-6693-d87c-f010-ca8ad502a39f@enterp! risedb.com>

Peter Eisentraut <[email protected]> writes:
> On 06.07.22 22:46, Tom Lane wrote:
>> ...  There is one nasty problem
>> we need a solution to, which is that pgindent is not at all on board
>> with this idea of attaching node attrs to typedefs.

> I have found that putting the attributes at the end of the struct 
> definition, right before the semicolon, works, so I have changed it that 
> way.  (This is also where a gcc __attribute__() would go, so it seems 
> reasonable.)

That was the first solution I thought of as well, but I do not like
it from a cosmetic standpoint.  The node attributes are a pretty
critical part of the node definition (especially "abstract"),
so shoving them to the very end is not helpful for readability.
IMO anyway.

> I think for this present patch, I would do a catversion bump, just to be 
> sure, in case some of the printed node fields are different now.

I know from comparing the code that some printed node tags have
changed, and so has the print order of some fields.  It might be
that none of those changes are in node types that can appear in
stored rules --- but I'm not sure, so I concur that doing a
catversion bump for this commit is advisable.

> It was also my plan to remove the #ifdef OBSOLETE sections in a separate 
> commit right after, just to be clear.

Yup, my thought as well.  There are a few other mop-up things
I want to do shortly after (e.g. add copyright-notice headers
to the emitted files), but let's wait for the buildfarm's
opinion of the main commit first.

> Final thoughts?

I'll re-read the patch today, but how open are you to putting the
struct attributes at the top?  I'm willing to do the legwork.

			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