Re: clearing opfuncid vs. parallel query

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Oct 22, 2015 at 1:40 PM, YUriy Zhuravlev
> <u(dot)zhuravlev(at)postgrespro(dot)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.) 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.

regards, tom lane