Re: automatically generating node support functions

What do people think about this patch now?

I have received some feedback on several small technical issues, which
have all been fixed. This patch has been around for several commit
fests now and AFAICT, nothing has broken it. This is just to indicate
that the parsing isn't as flimsy as one might fear.

One thing thing that is waiting behind this patch is that you currently
cannot put utility commands into parse-time SQL functions, because there
is no full out/read support for those. This patch would fix that
problem. (There is a little bit of additional work necessary, but I
have that mostly worked out in a separate branch.)

On 24.01.22 16:15, Peter Eisentraut wrote:
> Rebased patch to resolve some merge conflicts
>
> On 29.12.21 12:08, Peter Eisentraut wrote:
>> On 12.10.21 15:52, Andrew Dunstan wrote:
>>> I haven't been through the whole thing, but I did notice this: the
>>> comment stripping code looks rather fragile. I think it would blow up if
>>> there were a continuation line not starting with  qr/\s*\*/. It's a lot
>>> simpler and more robust to do this if you slurp the file in whole.
>>> Here's what we do in the buildfarm code:
>>>
>>>      my $src = file_contents($_);
>>>      # strip C comments
>>>      # We used to use the recipe in perlfaq6 but there is actually no
>>> point.
>>>      # We don't need to keep the quoted string values anyway, and
>>>      # on some platforms the complex regex causes perl to barf and
>>> crash.
>>>      $src =~ s{/\*.*?\*/}{}gs;
>>>
>>> After you've done that splitting it into lines is pretty simple.
>>
>> Here is an updated patch, with some general rebasing, and the above
>> improvement.  It now also generates #include lines necessary in
>> copyfuncs etc. to pull in all the node types it operates on.
>>
>> Further, I have looked more into the "metadata" approach discussed in
>> [0].  It's pretty easy to generate that kind of output from the data
>> structures my script produces.  You just loop over all the node types
>> and print stuff and keep a few counters.  I don't plan to work on that
>> at this time, but I just wanted to point out that if people wanted to
>> move into that direction, my patch wouldn't be in the way.
>>
>>
>> [0]:
>> https://www.postgresql.org/message-id/flat/20190828234136.fk2ndqtld3onfrrp%40alap3.anarazel.de
>>