Re: max(*)
От | Jim C. Nasby |
---|---|
Тема | Re: max(*) |
Дата | |
Msg-id | 20060526190629.GF59464@pervasive.com обсуждение исходный текст |
Ответ на | Re: max(*) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: max(*)
Re: max(*) |
Список | 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 по дате отправления: