Skip site navigation (1)
Skip section navigation (2)
Peripheral Links
Header And Logo
|
Site Navigation
Re: max(*)
- From: Bruno Wolff III <bruno(at)wolff(dot)to>
- To: "Jim C. Nasby" <jnasby(at)pervasive(dot)com>
- Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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: Fri, 26 May 2006 14:35:20 -0500
- Message-id: <20060526193520(dot)GA24444(at)wolff(dot)to>
On Fri, May 26, 2006 at 14:06:29 -0500, "Jim C. Nasby" <jnasby(at)pervasive(dot)com> wrote: > > 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. :) Tom's suggestion that (*) map to () which would refer to a zero argument aggregate would cover this case, since there wouldn't be a zero argument version of max.
- References:
- max(*)
- From: Dennis Bjorklund
- Re: max(*)
- From: Simon Riggs
- Re: max(*)
- From: Tom Lane
- Re: max(*)
- From: Jim C. Nasby
- max(*)
- Prev by Date: Re: max(*)
- Next by Date: Re: max(*)
- Previous by thread: Re: max(*)
- Next by thread: Re: max(*)
- Indexes: