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
