Re: [HACKERS] GROUP BY fixes committed

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] GROUP BY fixes committed
Date: 1999-05-10 16:54:47
Message-ID: 199905101654.MAA07883@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Nice summary. Where are we on the last item.

> I just committed a rewrite of union_planner, make_groupPlan, and
> related routines that corrects several of the bugs we've been
> seeing lately. In particular, cases involving nontrivial GROUP BY
> expressions work again. The core of the problem was that the
> EXCEPT/HAVING patch broke some extremely delicate (and quite
> undocumented) interactions between these routines. I decided
> rewrite was better than (another layer of) patch, especially
> since I could document along the way.
>
> There are closely associated bugs in the rewriter and parser that
> I have not gone after. Jan's example still fails:
>
> CREATE TABLE t1 (a int4, b int4);
> CREATE VIEW v1 AS SELECT b, count(b) FROM t1 GROUP BY b;
>
> SELECT count FROM v1;
>
> because the rewriter is mislabeling both the target column 'count'
> and the group-by column 'b' with resno 1. More interestingly,
> given the same view
>
> SELECT b FROM v1;
>
> also fails, even though there is no resno conflict. The problem in
> this case is that the query is marked hasAggs, even though all the
> aggregates have been optimized out. By the time the planner realizes
> that there are not in fact any aggregates, it's too late to recover
> easily, so for now I just made it report an error. Jan, how hard would
> it be to make the rewriter tell the truth in this case?
>
> Also, the problem Michael Davis reported on 4/29 seems to be in the
> parser:
>
> insert into si_tmpVerifyAccountBalances select invoiceid+3, memberid, 1,
> TotShippingHandling from InvoiceLineDetails where TotShippingHandling <> 0
> and InvoiceLinesID <= 100 group by invoiceid+3, memberid,
> TotShippingHandling;
> ERROR: INSERT has more expressions than target columns
>
> since that error message appears only in the parser. Thomas, did you
> change anything recently in parsing of INSERT ... SELECT?
>
> regards, tom lane
>
>

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-05-10 17:06:36 Re: [HACKERS] problems with parser
Previous Message Bruce Momjian 1999-05-10 16:52:57 Re: [HACKERS] It would be nice if this could be fixed...