Re: automatically generating node support functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: automatically generating node support functions
Date: 2022-02-14 17:09:47
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> What do people think about this patch now?

I'm in favor of moving forward with this. I do not like the
libclang-based approach that Andres was pushing, because of the
jump in developer tooling requirements that it'd cause.

Eyeballing the patch a bit, I do have some comments:

* It's time for action on the business about extracting comments
from the to-be-deleted code.

* The Perl script is kind of under-commented for my taste.
It lacks a copyright notice, too.

* In the same vein, I should not have to reverse-engineer what
the available pg_node_attr() properties are or do. Perhaps they
could be documented in the comment for the pg_node_attr macro
in nodes.h.

* Maybe the generated file names could be chosen less opaquely,
say ".funcs" and ".switch" instead of ".inc1" and ".inc2".

* I don't understand why there are changes in the #include
lists in copyfuncs.c etc?

* I think that more thought needs to be put into the format
of the *nodes.h struct declarations, because I fear pgindent
is going to make a hash of what you've done here. When we
did similar stuff in the catalog headers, I think we ended
up moving a lot of end-of-line comments onto their own lines.

* I assume the pg_config_manual.h changes are not meant for

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Chapman Flack 2022-02-14 17:25:36 Re: Mark all GUC variable as PGDLLIMPORT
Previous Message Christoph Heiss 2022-02-14 17:00:11 Re: [PATCH] Add reloption for views to enable RLS