From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | jwieck(at)debis(dot)com (Jan Wieck) |
Cc: | maillist(at)candle(dot)pha(dot)pa(dot)us, hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] 6.5 TODO list |
Date: | 1999-05-11 18:20:21 |
Message-ID: | 14065.926446821@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
jwieck(at)debis(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-05-11 18:23:26 | Re: [HACKERS] 6.5 TODO list |
Previous Message | Tom Lane | 1999-05-11 18:08:04 | Re: [HACKERS] Re: [SQL] plpgsql error |