Re: [HACKERS] DISTINCT ON: speak now or forever hold your peace
| От | Tom Lane |
|---|---|
| Тема | Re: [HACKERS] DISTINCT ON: speak now or forever hold your peace |
| Дата | |
| Msg-id | 18389.948912054@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: [HACKERS] DISTINCT ON: speak now or forever hold your peace (Peter Eisentraut <peter_e@gmx.net>) |
| Ответы |
Re: [HACKERS] DISTINCT ON: speak now or forever hold your peace
|
| Список | pgsql-sql |
Peter Eisentraut <peter_e@gmx.net> writes:
> Our documents say that DISTINCT ON is equivalent to GROUP BY. I still
> don't see why that wouldn't be true. You can always rewrite
> select distinct on a a,b from test
> as
> select a, xxx(b) from test group by a
> where xxx is some aggregate function (presumably min or max).
Not really. Look at Julian's example. He can't rewrite as
select a, min(b), min(c) from test group by a
because the idea is to get the c that corresponds to the min b.
If you do it with two independent aggregates then the b and c
you get back may be from different tuples.
I could imagine fixing this with a two-input aggregate, say
select a, min(b), keyofmin(b, c) from test group by a
where keyofmin is defined to return the c associated with the min b.
But that'd be a pain to implement, first because we have no support
for multi-argument aggregates, and second because you'd need a ton
of separate keyofmin implementations for the cross-product of the
data types you might want to deal with. So this is nearly as
klugy as the SELECT DISTINCT ON approach --- and not any more
standard, either.
regards, tom lane
В списке pgsql-sql по дате отправления: