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
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 |