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 по дате отправления:

Предыдущее
От: Jan Wieck
Дата:
Сообщение: Re: RULE vs. SEQUENCE
Следующее
От: Thomas Lockhart
Дата:
Сообщение: Re: Viability of VARLENA_FIXED_SIZE()