From: | jwieck(at)debis(dot)com (Jan Wieck) |
---|---|
To: | maillist(at)candle(dot)pha(dot)pa(dot)us (Bruce Momjian) |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, jwieck(at)debis(dot)com, hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] 6.5 TODO list |
Date: | 1999-05-12 10:26:50 |
Message-ID: | m10hWDy-000EBaC@orion.SAPserv.Hamburg.dsh.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)debis(dot)com (Jan Wieck) #
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 1999-05-12 10:37:24 | Re: [HACKERS] Re: [SQL] plpgsql error |
Previous Message | Jan Wieck | 1999-05-12 10:22:03 | Re: [HACKERS] More on GROUP BY |