From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | M(dot)Mazurek(at)poznan(dot)multinet(dot)pl |
Cc: | pgsql-sql(at)postgreSQL(dot)org |
Subject: | Re: [SQL] date_part, too many results? |
Date: | 2000-02-25 00:46:20 |
Message-ID: | 23632.951439580@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
M(dot)Mazurek(at)poznan(dot)multinet(dot)pl writes:
> clicked table is empty for bannerid=1, so why is that row? How to get rid
> bannerdb=> select count(*),date_part('dow',data::datetime) from clicked
> where bannerid=1 group by date_part('dow',data::datetime);
> count|date_part
> -----+---------
> 0|
> (1 row)
It's not date_part's fault, it's count's fault. There should be no rows
out if you have GROUP BY and no groups, but 6.5 and prior Postgres
releases emit a dummy row anyway. This is a longstanding bug in
Postgres's handling of aggregate functions. It's fixed for 7.0, if you
want to try running the beta version... if not, you could add
HAVING count(*) > 0 as a temporary workaround.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-02-25 01:03:37 | Re: [INTERFACES] arrays of varchar and " |
Previous Message | Tom Lane | 2000-02-24 23:57:50 | Re: [SQL] how to create index on timestamp field in pre v7 database |