Re: pgsql: Revise parse tree representation for VACUUM and ANALYZE. - Mailing list pgsql-committers

From Tom Lane
Subject Re: pgsql: Revise parse tree representation for VACUUM and ANALYZE.
Date
Msg-id 9072.1553003775@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgsql: Revise parse tree representation for VACUUM and ANALYZE.  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-committers
Masahiko Sawada <sawada.mshk@gmail.com> writes:
> On Tue, Mar 19, 2019 at 11:01 AM Michael Paquier <michael@paquier.xyz> wrote:
>> On Mon, Mar 18, 2019 at 09:53:23PM -0400, Tom Lane wrote:
>>> The buildfarm's not too happy with this, which I suspect traces
>>> to the fact that you neglected to fix copyfuncs.c and equalfuncs.c.

>> If you use -DDCOPY_PARSE_PLAN_TREES -DRAW_EXPRESSION_COVERAGE_TEST, I
>> am pretty sure that you will be able to reproduce those failures.

> Thank you for the information. I'll test with that options before
> submitting a patch.

You shouldn't really have needed the buildfarm to point you to doing
that.  *Any* change to Node structures requires looking into the
backend/node/ files, i.e. copyfuncs.c, equalfuncs.c, outfuncs.c,
readfuncs.c, nodeFuncs.c.  There are some classes of Nodes that
can get away without coverage in one or more of those, but certainly
if you're changing an existing Node struct you should just grep to
see if what you're changing is already mentioned in there.

(I tend to just grep the entire tree, if practical, for references
to a node structure that I'm changing.)

            regards, tom lane


pgsql-committers by date:

Previous
From: Peter Eisentraut
Date:
Subject: pgsql: Reorder LOCALLOCK structure members to compact the size
Next
From: Alvaro Herrera
Date:
Subject: Re: pgsql: Revise parse tree representation for VACUUM and ANALYZE.