Re: OO inheritance implementation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: OO inheritance implementation
Date
Msg-id 14265.968084956@sss.pgh.pa.us
Whole thread Raw
In response to OO inheritance implementation  (Chris <chrisb@nimrod.itg.telstra.com.au>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: RULE vs. SEQUENCE
Next
From: Thomas Lockhart
Date:
Subject: Re: Viability of VARLENA_FIXED_SIZE()