Re: automatically generating node support functions - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: automatically generating node support functions
Date
Msg-id 45f508cb-e30b-c252-e081-4548deafa34c@enterprisedb.com
Whole thread Raw
In response to Re: automatically generating node support functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: automatically generating node support functions
Re: automatically generating node support functions
List pgsql-hackers
On 11.07.22 01:09, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
>> I was just rebasing meson ontop of this and was wondering whether the input
>> filenames were in a particular order:

First, things used by later files need to be found in earlier files.  So 
that constrains the order a bit.

Second, the order of the files determines the ordering of the output. 
The current order of the files reflects approximately the order how the 
manual code was arranged.  That could be changed.  We could also just 
sort the node types in the script and dump out everything alphabetically.

> That annoyed me too.  I think it's sensible to list the "main" input
> files first, but I'd put them in our traditional pipeline order:
> 
>>     nodes/nodes.h \
>>     nodes/primnodes.h \
>>     nodes/parsenodes.h \
>>     nodes/pathnodes.h \
>>     nodes/plannodes.h \
>>     nodes/execnodes.h \

The seems worth trying out.

> The rest could probably be alphabetical.  I was also wondering if
> all of them really need to be read at all --- I'm unclear on what
> access/sdir.h is contributing, for example.

could not handle type "ScanDirection" in struct "IndexScan" field 
"indexorderdir"



pgsql-hackers by date:

Previous
From: Jean Carlo Giambastiani Lopes
Date:
Subject: Foreign Key constraints on xocolatl/periods
Next
From: Tom Lane
Date:
Subject: Re: Making CallContext and InlineCodeBlock less special-case-y