Re: [HACKERS] bug with aggregates

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Massimo Dal Zotto <dz(at)cs(dot)unitn(dot)it>
Cc: hackers(at)postgreSQL(dot)org (PostgreSQL Hackers)
Subject: Re: [HACKERS] bug with aggregates
Date: 1999-06-12 16:42:32
Message-ID: 15478.929205752@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Massimo Dal Zotto <dz(at)cs(dot)unitn(dot)it> writes:
> dz=> select count(1) from my_table;
> pqReadData() -- backend closed the channel unexpectedly.

Further notes --- I find that you can get the same crash with no table
at all,
select count(1);

6.4.2 executes both queries --- but curiously enough, it produces "1"
regardless of the size of the table you mention, which is not surprising
when you look at its plan ... it optimizes out the scan of the table
entirely. But if you do
select a,count(1) from table group by a;
then you get a count of the number of rows in each group, which is more
or less what I'd expect. This behavior is not consistent with the
ungrouped case.

After a quick gander at the SQL spec, I see no evidence that either of
these queries is allowed by the spec. I'm inclined to think that
"select count(1);" ought to be disallowed and "select count(1) from
my_table;" ought to be treated the same as "select count(*) from
my_table;", like it is in the grouped case. Comments?

regards, tom lane

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 1999-06-12 18:16:53 Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem
Previous Message Tom Lane 1999-06-12 16:21:21 Re: [HACKERS] bug with aggregates