On Thu, Oct 22, 2015 at 4:32 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> On Thu, Oct 22, 2015 at 1:40 PM, YUriy Zhuravlev
>> <u.zhurav...@postgrespro.ru> wrote:
>>> I can gen xml/json from actual struct. I offered XML/JSON as the analysis 
>>> of C
>>> code much more difficult. But my current generator just use the structure 
>>> from
>>> the header files (by pycparser).
>> Anything that is part of the build process will have to be done in C or Perl.
> Yeah.  The bar for introducing new build tool requirements is very high;
> *way* higher than the likely benefit from not having to hand-maintain
> outfuncs.c et al.  If you wanna do this in Perl, fine, but we're not going
> to introduce a requirement to have Python to build just because somebody
> wants to write a tool in the latter not the former.
> Having said that, there is more knowledge embedded in the nodes/*.c files
> than there is in the nodes/*.h headers; an example being that there are
> certain fields that we deliberately don't dump and restore.  (This is
> still true despite Robert's recent changes to take opfuncid out of that
> class.)

Are those things, ah, documented somewhere?

> I'm not sure that you could get to a point where you were
> generating this stuff from anything that wasn't in essence an arcane
> representation of the .c files.  It might be slightly harder to make
> errors of omission that way, but I'm suspicious that that would come at
> the cost of a net loss of readability.

That is possible, but the current situation isn't good either.
Despite everybody's best efforts, we mess this up more than is really
desirable. Commit b8fe12a83622b350dc6849f8bb933bd8a86c1424 fixed bugs
in a whole bunch of preceding commits, and I wonder if anybody else
would have found those if Noah hadn't.  It's just too easy to miss
these things today.  If generating the .c files isn't practical,
another alternative worth exploring would be a tool to cross-check
them against the .h files.

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to