Re: [HACKERS] 6.5 TODO list

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

Responses

Browse pgsql-hackers by date

  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