Re: [HACKERS] 6.5 TODO list

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) #

In response to

Browse pgsql-hackers by date

  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