Re: automatically generating node support functions

Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> 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