On Fri, Jan 5, 2018 at 2:50 PM, Andres Freund wrote:
> Agreed on that. But I also think there's quite some room for
> centralizing some of the work done in the init routines. Not quite sure
> how, but I do dislike the amount of repetition both in code and
> comments.
+1.
I *assume* that if you r
Andres Freund writes:
> On 2018-01-05 10:36:19 -0500, Tom Lane wrote:
>> Ashutosh Bapat writes:
>>> I am wondering why don't we instead save estate in ExecInitNode() itself
>>> like
>>> result->estate = estate;
>> That would only work if there were no situation where the field needed to
>> be a
On 2018-01-05 10:36:19 -0500, Tom Lane wrote:
> Ashutosh Bapat writes:
> > Looking at ExecInitXYZ() functions, we can observe that every such
> > function has a statement like
> > XYZstate->ps.state = estate;
> > where it saves estate in the PlanState.
>
> Yeah ...
>
> > I am wondering why don't
Ashutosh Bapat writes:
> Looking at ExecInitXYZ() functions, we can observe that every such
> function has a statement like
> XYZstate->ps.state = estate;
> where it saves estate in the PlanState.
Yeah ...
> I am wondering why don't we instead save estate in ExecInitNode() itself like
> result->
Hi,
Looking at ExecInitXYZ() functions, we can observe that every such
function has a statement like
XYZstate->ps.state = estate;
where it saves estate in the PlanState.
I am wondering why don't we instead save estate in ExecInitNode() itself like
result->estate = estate;
Are there any cases w
