MIME-Version: 1.0
References: <c1097590-a6a4-486a-64b1-e1f9cc0533ce@enterprisedb.com>
 <2f876203-7142-fa71-6d22-6ce00eb26869@enterprisedb.com>
 <c091e5cd-45f8-69ee-6a9b-de86912cc7e7@enterprisedb.com>
 <b85eec6e-a54b-6c72-97f8-2a6fbf4f9070@enterprisedb.com>
 <c683a356-4d22-4126-bf55-64ed54e06014@enterprisedb.com>
 <50fedc80-4104-bdc8-d777-04f030fc550f@dunslane.net>
 <7848b872-7a10-67b2-b55f-7c9c475ae863@enterprisedb.com>
 <40a2e977-98ba-0c01-af6c-9dfb39e864ba@enterprisedb.com>
 <812ea8eb-6827-ba32-6ec0-6714f7ffa5dd@enterprisedb.com>
 <2905876.1644858587@sss.pgh.pa.us>
 <bee9fdb0-cd10-5fdb-3027-c4b5a240bc74@enterprisedb.com>
In-Reply-To: <bee9fdb0-cd10-5fdb-3027-c4b5a240bc74@enterprisedb.com>
From: David Rowley <dgrowleyml@gmail.com>
Date: Fri, 25 Mar 2022 10:57:29 +1300
Message-ID: 
 <CAApHDvppoxUxzRJbwF9oOF12ngdfNoPEMfDsu63+LREgGnheUw@mail.gmail.com>
Subject: Re: automatically generating node support functions
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAApHDvppoxUxzRJbwF9oOF12ngdfNoPEMfDsu63%2BLREgGnheUw%40mail.gmail.com>
Precedence: bulk

On Fri, 18 Feb 2022 at 19:52, Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
> [ v5-0001-Automatically-generate-node-support-functions.patch ]

I've been looking over the patch and wondering the best way to move
this forward.

But first a couple of things I noted down from reading the patch:

1. You're written:

 * Unknown attributes are ignored.  Some additional attributes are used for
 * special "hack" cases.

I think these really should all be documented.  If someone needs to
use one of these hacks then they're going to need to trawl through
Perl code to see if you've implemented something that matches the
requirements.  I'd personally rather not have to look at the Perl code
to find out which attributes I need to use for my new field. I'd bet
I'm not the only one.

2. Some of these comment lines have become pretty long after having
added the attribute macro.

e.g.

PlannerInfo *subroot pg_node_attr(readwrite_ignore); /* modified
"root" for planning the subquery;
   not printed, too large, not interesting enough */

I wonder if you'd be better to add a blank line above, then put the
comment on its own line, i.e:

 /* modified "root" for planning the subquery; not printed, too large,
not interesting enough */
PlannerInfo *subroot pg_node_attr(readwrite_ignore);

3. My biggest concern with this patch is it introducing some change in
behaviour with node copy/equal/read/write.  I spent some time in my
diff tool comparing the files the Perl script built to the existing
code.  Unfortunately, that job is pretty hard due to various order
changes in the outputted functions.  I wonder if it's worth making a
pass in master and changing the function order to match what the
script outputs so that a proper comparison can be done just before
committing the patch.   The problem I see is that master is currently
a very fast-moving target and a detailed comparison would be much
easier to do if the functions were in the same order. I'd be a bit
worried that someone might commit something that requires some special
behaviour and that commit goes in sometime between when you've done a
detailed and when you commit the full patch.

Although, perhaps you've just been copying and pasting code into the
correct order before comparing, which might be good enough if it's
simple enough to do.

I've not really done any detailed review of the Perl code. I'm not the
best person for that, but I do feel like the important part is making
sure the outputted files logically match the existing files.

Also, I'm quite keen to see this work make it into v15.  Do you think
you'll get time to do that? Thanks for working on it.

David