Thread: OO inheritance implementation

I'm trying to figure out how to implement the behaviour of returning all
subclass fields. i.e. the "SELECT **" behaviour talked about in the
past.

What I'm thinking is that transformTargetList will do the same thing as
per "*" except that it will set another flag "and_the_rest".

plan_inherit_queries will then notice the flag and then expand the
target list as per each sub-class.

This seems to be the way to do it as far as I can see. It doesn't seem
ideal is so far as "*" and "**" would not be handled in the same place,
but since currently "*" and the breaking up of inheritance queries into
an append plan happen in different places, this seems inevitable unless
one were to totally rearrange the order things are done in the backend.

Any comments?

Chris <chrisb@nimrod.itg.telstra.com.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?) but also broken for OUTER JOIN.  In an
outer join, concatenating the final query results is not isomorphic to
concatenating the child class contents and then doing the query, which
is how I'd expectSELECT * FROM classA OUTER JOIN classB*
to behave.

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

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?

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.
        regards, tom lane

Tom Lane wrote:
> 
> Chris <chrisb@nimrod.itg.telstra.com.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.