Re: [HACKERS] Bug or feature? select, count(*), group by and empty tables

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Don Baccus <dhogaza(at)pacifier(dot)com>
Cc: hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Bug or feature? select, count(*), group by and empty tables
Date: 1999-12-15 05:52:15
Message-ID: 17081.945237135@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Don Baccus <dhogaza(at)pacifier(dot)com> writes:
> (always returning a row for a select count(*) ... group by query
> even if there aren't any groups)

Yah: if you have aggregates and no GROUP, for empty input you should
get one row out with "default" results (0 for COUNT, null for most other
aggregates). But for GROUP mode, no rows in should yield no rows out,
aggregates or no. It took a fair amount of arguing before everyone was
convinced that that is the correct interpretation of the spec ;-),
which is why it's only been fixed recently.

> OK, I've gotten the latest sources with the bright idea of digging
> around, and in nodeAgg.c the routine ExecAgg.c has been somewhat
> rewritten, with comments that make it clear that this bug's already
> been fixed.
> I should build myself a latest version so I can filter out non-problems
> before reporting them, sorry...

Not a problem. Bug reports on the latest release are fair game.
If it's already been fixed in current sources, whoever fixed it
will surely take pleasure in telling you so...

regards, tom lane

Browse pgsql-hackers by date

  From Date Subject
Next Message Oleg Bartunov 1999-12-15 08:15:38 postmaster dies (6.5.3)
Previous Message Bruce Momjian 1999-12-15 02:52:14 Re: [HACKERS] Volunteer: Large Tuples / Tuple chaining