Re: OO inheritance implementation
От | Tom Lane |
---|---|
Тема | Re: OO inheritance implementation |
Дата | |
Msg-id | 14265.968084956@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | OO inheritance implementation (Chris <chrisb@nimrod.itg.telstra.com.au>) |
Список | 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 по дате отправления: