automatically generating node support functions

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема automatically generating node support functions
Дата
Msg-id c1097590-a6a4-486a-64b1-e1f9cc0533ce@enterprisedb.com
обсуждение исходный текст
Ответы Re: automatically generating node support functions  (David Rowley <dgrowleyml@gmail.com>)
Re: automatically generating node support functions  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Список 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.

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: CALL versus procedures with output-only arguments
Следующее
От: Tom Lane
Дата:
Сообщение: Re: CALL versus procedures with output-only arguments