From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kovacs Zoltan Sandor <tip(at)pc10(dot)radnoti-szeged(dot)sulinet(dot)hu> |
Cc: | pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: bug in views/aggregates |
Date: | 2000-10-26 03:01:08 |
Message-ID: | 4048.972529268@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Kovacs Zoltan Sandor <tip(at)pc10(dot)radnoti-szeged(dot)sulinet(dot)hu> writes:
> I'm not sure if this is a reported bug or not. SELECT statements with some
> aggregates on certain complex views can give terrible results. An example:
Aggregates on grouped views do not and cannot work in 7.0 or earlier
releases, because the existing rewriter implementation cannot cause the
system to do multiple rounds of grouping/aggregation. Unfortunately
the rewriter is usually not bright enough to realize it can't do the
right thing, either :-(
This is fixed for 7.1. In current sources your example produces
regression=# SELECT count(*) FROM buggy_view;
count
-------
2
(1 row)
> I am interested in workarounds as well.
For now, you could select the view's results into a temp table,
and then aggregate over the table.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-10-26 03:15:31 | Re: Slack7.1/linux.2.4 compile error: storage size of `semun' isn't known |
Previous Message | pgsql-bugs | 2000-10-25 21:33:18 | Slack7.1/linux.2.4 compile error: storage size of `semun' isn't known |
From | Date | Subject | |
---|---|---|---|
Next Message | The Hermit Hacker | 2000-10-26 03:55:55 | Re: latest version? |
Previous Message | Marko Kreen | 2000-10-25 21:37:13 | Re: [Fwd: [CORE SDI ADVISORY] MySQL weak authentication] |