Re: max(*) - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: max(*)
Date
Msg-id 20060526190629.GF59464@pervasive.com
Whole thread Raw
In response to Re: max(*)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: max(*)
Re: max(*)
List pgsql-hackers
On Fri, May 26, 2006 at 11:03:17AM -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > On Fri, 2006-05-26 at 10:22 +0200, Dennis Bjorklund wrote:
> >> Shouldn't
> >> SELECT max(*) FROM foo;
> >> give an error? 
> 
> > Doesn't seem an important or even useful extension of the standard, but
> > would probably require special case processing for every aggregate
> > function in order to implement that. Its not dangerous... so I'm not
> > sure we should take any action at all.
> 
> We shouldn't.  The spec's prohibition is based on the assumption that
> the only aggregate functions in existence are those listed in the spec.
> Since we allow user-defined aggregates, who are we to say that there are
> no others for which "*" is sensible?

But if aggregate(*) just gets turned into aggregate(1) by the backend,
why not just tell people to use aggregate(1) for their custom
aggregates? Or am I misunderstanding how aggregate(*) is actually
handled?

My concern is that it's not inconceiveable to typo max(field) into
max(*), which could make for a rather frustrating error. Not to mention
this being something that could trip newbies up. If nothing else I'd say
it warrants a %TODO just so it doesn't end up on the PostgreSQL gotcha's
page. :)
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461


pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Creating a case insensitive data type
Next
From: Bruno Wolff III
Date:
Subject: Re: max(*)