Re: proposal: tuplestore, tuplesort aggregate functions
От | Robert Haas |
---|---|
Тема | Re: proposal: tuplestore, tuplesort aggregate functions |
Дата | |
Msg-id | AANLkTi=2sxfSUh1Swo7XuO4vdQUwcT+Ff9DNHy5Vvzm1@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: proposal: tuplestore, tuplesort aggregate functions (David Fetter <david@fetter.org>) |
Ответы |
Re: proposal: tuplestore, tuplesort aggregate functions
|
Список | pgsql-hackers |
On Thu, Aug 19, 2010 at 5:53 PM, David Fetter <david@fetter.org> wrote: > On Thu, Aug 19, 2010 at 05:40:46PM -0400, Tom Lane wrote: >> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes: >> > Robert Haas <robertmhaas@gmail.com> wrote: >> >> I suppose there could also be a bit of an ambiguity if you're working >> >> with a type like int4 where the values are discrete steps. Like, what >> >> do you do with {1, 2}? >> >> Hmm, good point. >> >> > The same thing you do with the avg function? >> >> avg's approach is not at all datatype-independent though. If you're >> willing to give up the idea of a polymorphic median() function, that >> would probably be the thing to do. If not, you need to take the left >> or right one of the two central elements. > > Whether the median needs to be in the sample is one question that > doesn't really have a universal right answer. A separate question, > also without a universal right answer, is whether the median needs to > be in the same domain as the sample, int4 being the case above. > > We could just go with "whatever Oracle, DB2 and MS-SQL Server have," > assuming it's the same thing, until something appears in the SQL > standard. That's usually a sensible default, when in doubt. If nothing else, it improves compatibility. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
В списке pgsql-hackers по дате отправления: