| 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: | Whole Thread | Raw Message | 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] |