On Tue, 26 Mar 2002, Jan Wieck wrote:
> Tom Lane wrote:
> > I think the existing scheme of generating the plan during first use
> > in a particular backend is fine. At least as long as we're sticking
> > with standard plans at all ... IIRC Stephan was wondering about
> > bypassing the whole parse/plan mechanism in favor of heap-access-level
> > operations.
>
> I don't know if using heap-access directly in the RI triggers
> is such a good idea.
>
> It is guaranteed that there is a unique key covering all the
> referenced columns (and only them). I'm not sure though if it
> has to be in the same column order as the reference. Nor do I
> think that matters other than making the creation of the
> scankey a bit more difficult.
>
> But there could be no, some, a full matching index, maybe one
> with extra columns at the end on the foreign key. So for the
> referential action, the entire process of deciding which
> index fits best, pushing some of the qualification into the
> index scankey, and do the rest on the heap tuples, has to be
> duplicated here.
That is the problem that I've run into in working on doing it. I'm
still trying to figure out what levels of that code can be used.
The advantage that I see is that we get more control over the time
qualifications used for tuples which may come into play for match
partial. I'm not sure that it's worth the effort to try doing it
this way, but I figured I'd try it.
