automatically generating node support functions - Mailing list pgsql-hackers

From Peter Eisentraut
Subject automatically generating node support functions
Date
Msg-id c1097590-a6a4-486a-64b1-e1f9cc0533ce@enterprisedb.com
Whole thread Raw
Responses Re: automatically generating node support functions
Re: automatically generating node support functions
List pgsql-hackers
I wrote a script to automatically generate the node support functions 
(copy, equal, out, and read, as well as the node tags enum) from the 
struct definitions.

The first eight patches are to clean up various inconsistencies to make 
parsing or generation easier.

The interesting stuff is in patch 0009.

For each of the four node support files, it creates two include files, 
e.g., copyfuncs.inc1.c and copyfuncs.inc2.c to include in the main file. 
  All the scaffolding of the main file stays in place.

In this patch, I have only ifdef'ed out the code to could be removed, 
mainly so that it won't constantly have merge conflicts.  Eventually, 
that should all be changed to delete the code.  When we do that, some 
code comments should probably be preserved elsewhere, so that will need 
another pass of consideration.

I have tried to mostly make the coverage of the output match what is 
currently there.  For example, one could do out/read coverage of utility 
statement nodes easily with this, but I have manually excluded those for 
now.  The reason is mainly that it's easier to diff the before and 
after, and adding a bunch of stuff like this might require a separate 
analysis and review.

Subtyping (TidScan -> Scan) is supported.

For the hard cases, you can just write a manual function and exclude 
generating one.

For the not so hard cases, there is a way of annotating struct fields to 
get special behaviors.  For example, pg_node_attr(equal_ignore) has the 
field ignored in equal functions.

There are a couple of additional minor issues mentioned in the script 
source.  But basically, it all seems to work.

Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: CALL versus procedures with output-only arguments
Next
From: Tom Lane
Date:
Subject: Re: CALL versus procedures with output-only arguments