Re: OO inheritance implementation

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?) 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 expect
SELECT * 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