Hi,
On 2019-08-24 12:13:22 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2019-07-31 22:37:40 -0400, Tom Lane wrote:
> > I briefly tried to implement that. The problem is that, as things are
> > currently set up, we don't have access to the corresponding epqstate
> > from within executor nodes. That prevents us from accessing
> > EPQState->{origslot, arowMarks}, which we need to actually be able to
> > fetch the rows to return.
> > We could solve that by referencing the EPQState from its EState (but not
> > from the "main" estate). I've wondered before whether that'd be better
> > than having various es_epq* fields in EState. I don't think it'd make
> > the modularity any worse, given that we're already referencing EPQstate
> > fields from with EState. If we moved es_epqTupleSlot into EPQState and
> > allocated it from within EvalPlanQualInit(), instead of
> > EvalPlanQualBegin(), we'd address your complaint that we now call that
> > earlier too.
> > Doesn't sound that hard. Seems like a big change for v12 though.
>
> I feel that this seems like a promising solution for the longer term.
> I agree that keeping a pointer to the whole EPQState in EState is no
> worse than having pointers to some of its fields there.
>
> Perhaps the next step is to draft a patch for this and see just how
> big it is compared to the minimal fix.
Working on that.
I just had a slightly crazy idea: What if we just blessed wholerow
rowmark types? Then we'd pretty trivially have access to the relevant
types? Or alternatively even just add type information to the
PlanRowMark for ROW_MARK_COPY instead of reconstructing it at runtime?
- Andres
