Thread

1. OO inheritance implementation

   Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> — 2000-09-04T05:51:35Z

   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?
   
   

2. Re: OO inheritance implementation

   Tom Lane <tgl@sss.pgh.pa.us> — 2000-09-04T16:29:16Z

   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 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
   
   

3. Re: OO inheritance implementation

   Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> — 2000-09-04T22:51:34Z

   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.