Re: clearing opfuncid vs. parallel query

On Thu, Oct 22, 2015 at 5:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Thu, Oct 22, 2015 at 4:32 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> 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.
>
> Yeah, I could get on board with that. It doesn't seem terribly hard:
> just make sure that all fields mentioned in the struct declaration are
> mentioned in each relevant routine. (Cases where we intentionally skip
> a field could be handled by adding a no-op macro, eg "COPY_IGNORE(foo);")
>
> It would be nice if we could also check that the macro type is sane for
> the field datatype (eg, not use COPY_SCALAR_FIELD() for a pointer field).
> But that would probably increase the difficulty very substantially for
> just a small gain in error detection.

I actually think that's quite an easy mistake to make, so I'd be happy
if we could catch it. But anything would be better than nothing.

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