Re: OO inheritance implementation

Tom Lane wrote:
>
> Chris <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au> writes:
> > plan_inherit_queries will then notice the flag and then expand the
> > target list as per each sub-class.
>
> Keep in mind that the existing implementation of inheritance expansion
> is not only pretty slow (is it *really* desirable to re-plan the whole
> query for each child class?)

Hmm. Sometimes it wouldn't be, at least when indexes that span
inheritance trees are implemented. I would imagine that it could be
desirable for different plans on occasion though.

> In this situation I think we'll need to push down the Append node to
> be executed just on classB*, before the join occurs.

So outer join is broken for inheritance queries?

> BTW, the notion of ** isn't even well-defined in this example: what set
> of classB child attributes would you propose to attach to the unmatched
> rows from classA?

Well ** is not enormously useful for doing joins in the first place
since its prime purpose is for constructing real objects on the client
side. I'm guessing that OQL doesn't support outer joins. But to nominate
a behaviour I would say the minimum set of fields as per * behaviour.

> The planner's inheritance code and UNION code are both unholy messes,
> and I have hopes of scrapping and rewriting essentially all of
> prepunion.c when we redo querytree structures for 7.2. So I'd advise
> not hanging a new-feature implementation on the existing code structure
> there.

Well if I leave it alone until you've done your querytree redesign, can
you keep this in mind for your design?

It's not clear in my mind what all the issues are, but moving around
differing tuples and knowing when a new set of tuples has started are
the issues in my mind.