On Thu, Oct 22, 2015 at 5:09 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Thu, Oct 22, 2015 at 4:32 PM, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers