From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Status report: subselect + grouping problems |
Date: | 1999-06-21 01:37:39 |
Message-ID: | 14292.929929059@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I have cleaned up some problems seen in the parser and planner when
a query involves both subselects and grouping ("grouping" = GROUP BY,
HAVING, and/or aggregate functions). I am not sure whether I've
fixed everything in those modules, though, because all my remaining
test cases are falling over due to rewriter bugs. For example:
CREATE TABLE t1 (name text, value float8);
CREATE
SELECT name FROM t1 WHERE name IN
(select name from t1 group by name having 2 = count(*));
ERROR: SELECT/HAVING requires aggregates to be valid
The trouble in this case is that the rewriter pushes count(*) down
into a third level of sub-select, which the planner quite rightly
decides is a constant with respect to the second level, whereupon
there don't seem to be any aggregates in the second-level subselect.
I'm not sufficiently clear about what the rewriter is trying to do here
to risk trying to fix it. I think the problem is a mistaken application
of modifyAggrefMakeSublink(), whose comment claims
* Create a sublink node for a qualification expression that
* uses an aggregate column of a view
There is no view nor aggregate column in sight here, but the routine
is getting invoked anyway. Jan, any thoughts?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Hollomon | 1999-06-21 01:39:30 | idea for 'module' support |
Previous Message | Tom Lane | 1999-06-20 23:22:39 | Re: [HACKERS] Update on my 6.4.2 progress |