Thread

  1. Re: [HACKERS] 6.5 TODO list

    Tom Lane <tgl@sss.pgh.pa.us> — 1999-05-11T18:20:21Z

    jwieck@debis.com (Jan Wieck) writes:
    >     The problem is that the planner modifies  the  targetlist  if
    >     the  operation  is an INSERT/DELETE by first creating a clean
    >     one representing the result relation and then moving the  old
    >     expressions  into. Then it adds some junk stuff and specially
    >     marked TLE's from the original targetlist.
    
    Right --- I imagine that doing that in the planner is a hangover from
    ancient history before the rewriter existed at all.  It does need to
    be done, but if you think it'd be better done in the rewriter that's
    fine with me.
    
    >     BUT - during this (preprocess_targetlist()) all  the  resno's
    >     can  get  reassigned and later the planner tries to match the
    >     GROUP BY entries only by resno. But the resno's in the  group
    >     clauses haven't been adjusted!
    
    Ugh.  I thought that was a pretty unrobust way of doing things :-(
    If you change the lines in planner.c:
    
            /* Is it safe to use just resno to match tlist and glist items?? */
            if (grpcl->entry->resdom->resno == resdom->resno)
    
    to use equal() on the expr's of the two TLEs, does it work any better?
    
    >     Currently I think the correct solution would be to expand the
    >     targetlist  already  in  the  rewrite  system  and  leave  it
    >     untouched in the planner. Comments?
    
    OK with me, but possibly rather a major change to be making this late
    in beta...
    
    			regards, tom lane
    
    
  2. Re: [HACKERS] 6.5 TODO list

    Bruce Momjian <maillist@candle.pha.pa.us> — 1999-05-11T18:37:41Z

    > Ugh.  I thought that was a pretty unrobust way of doing things :-(
    > If you change the lines in planner.c:
    > 
    >         /* Is it safe to use just resno to match tlist and glist items?? */
    >         if (grpcl->entry->resdom->resno == resdom->resno)
    > 
    > to use equal() on the expr's of the two TLEs, does it work any better?
    > 
    > >     Currently I think the correct solution would be to expand the
    > >     targetlist  already  in  the  rewrite  system  and  leave  it
    > >     untouched in the planner. Comments?
    > 
    > OK with me, but possibly rather a major change to be making this late
    > in beta...
    
    But it is already broken.  Can't get worse, can it?
    
    -- 
      Bruce Momjian                        |  http://www.op.net/~candle
      maillist@candle.pha.pa.us            |  (610) 853-3000
      +  If your life is a hard drive,     |  830 Blythe Avenue
      +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
    
    
  3. Re: [HACKERS] 6.5 TODO list

    Jan Wieck <jwieck@debis.com> — 1999-05-12T10:26:50Z

    Bruce Momjian wrote:
    
    >
    > > Ugh.  I thought that was a pretty unrobust way of doing things :-(
    > > If you change the lines in planner.c:
    > >
    > >         /* Is it safe to use just resno to match tlist and glist items?? */
    > >         if (grpcl->entry->resdom->resno == resdom->resno)
    > >
    > > to use equal() on the expr's of the two TLEs, does it work any better?
    > >
    > > >     Currently I think the correct solution would be to expand the
    > > >     targetlist  already  in  the  rewrite  system  and  leave  it
    > > >     untouched in the planner. Comments?
    > >
    > > OK with me, but possibly rather a major change to be making this late
    > > in beta...
    >
    > But it is already broken.  Can't get worse, can it?
    
        And  just  using  equal()  wouldn't  be enough. I tested what
        happens if the rewriter add's junk TLE's  for  group  clauses
        coming  from  a  view.  If the query is a SELECT, anything is
        fine, but if it is an INSERT ...  SELECT then the added TLE's
        needed    by    the    group    clauses   get   lost   during
        preprocess_targetlist().
    
    
    Jan
    
    --
    
    #======================================================================#
    # It's easier to get forgiveness for being wrong than for being right. #
    # Let's break this rule - forgive me.                                  #
    #======================================== jwieck@debis.com (Jan Wieck) #