Re: pgsql: Revise parse tree representation for VACUUM and ANALYZE.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Robert Haas <rhaas(at)postgresql(dot)org>, pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Revise parse tree representation for VACUUM and ANALYZE.
Date: 2019-03-19 13:56:15
Message-ID: 9072.1553003775@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> writes:
> On Tue, Mar 19, 2019 at 11:01 AM Michael Paquier <michael(at)paquier(dot)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

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Alvaro Herrera 2019-03-19 14:09:25 Re: pgsql: Revise parse tree representation for VACUUM and ANALYZE.
Previous Message Peter Eisentraut 2019-03-19 13:23:37 pgsql: Reorder LOCALLOCK structure members to compact the size