Skip site navigation (1) Skip section navigation (2)

Re: max(*)

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: max(*)
Date: 2006-05-26 19:06:29
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, May 26, 2006 at 11:03:17AM -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)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

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(at)pervasive(dot)com
Pervasive Software    work: 512-231-6117
vcard:       cell: 512-569-9461

In response to


pgsql-hackers by date

Next:From: Bruno Wolff IIIDate: 2006-05-26 19:35:20
Subject: Re: max(*)
Previous:From: Martijn van OosterhoutDate: 2006-05-26 18:50:05
Subject: Re: Creating a case insensitive data type

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group