From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Use outerPlanState macro instead of referring to leffttree |
Date: | 2022-07-06 14:48:21 |
Message-ID: | 2195795.1657118901@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> On Sat, Jul 2, 2022 at 5:32 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Backing up a little bit, one thing not to like about the outerPlanState
>> and innerPlanState macros is that they lose all semblance of type
>> safety:
> Your concern makes sense. I think outerPlan and innerPlan macros share
> the same issue. Not sure if there is a way to do the type check.
Yeah, I don't know of one either. It needn't hold up this patch.
>> Would it make sense to try to use the local-variable style everywhere?
> Do you mean the pattern like below?
> outerPlanState(hashstate) = ExecInitNode(outerPlan(node), estate, eflags);
> It seems that this pattern is mostly used when initializing child nodes
> with ExecInitNode(), and most calls to ExecInitNode() are using this
> pattern as a convention. Not sure if it's better to change them to
> local-variable style.
That's probably fine, especially if it's a commonly used pattern.
Typically, if one applies outerPlan() or outerPlanState() to the
wrong pointer, the mistake will become obvious upon even minimal
testing. My concern here is more about usages in edge cases that
perhaps escape testing, for instance in the arguments of an
elog() for some nearly-can't-happen case.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2022-07-06 15:01:39 | Re: Custom tuplesorts for extensions |
Previous Message | Matthias van de Meent | 2022-07-06 14:41:44 | Re: Custom tuplesorts for extensions |