Re: [HACKERS] 6.5 TODO list - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] 6.5 TODO list
Date
Msg-id 14065.926446821@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] 6.5 TODO list  (jwieck@debis.com (Jan Wieck))
Responses Re: [HACKERS] 6.5 TODO list  (Bruce Momjian <maillist@candle.pha.pa.us>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Re: [SQL] plpgsql error
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] 6.5 TODO list