Re: clearing opfuncid vs. parallel query - Mailing list pgsql-hackers

From Robert Haas
Subject Re: clearing opfuncid vs. parallel query
Date
Msg-id CA+Tgmoaij_73w8cSyZrMzhV8-SnkGmMixMufDY4UyaB+YYsk0Q@mail.gmail.com
Whole thread Raw
In response to Re: clearing opfuncid vs. parallel query  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: clearing opfuncid vs. parallel query  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Oct 22, 2015 at 4:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, Oct 22, 2015 at 1:40 PM, YUriy Zhuravlev
>> <u.zhuravlev@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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: shm_mq fix for non-blocking mode
Next
From: Robert Haas
Date:
Subject: Re: ATT_FOREIGN_TABLE and ATWrongRelkindError()