Re: [PATCH] Negative Transition Aggregate Functions (WIP) - Mailing list pgsql-hackers

From Florian Pflug
Subject Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Date
Msg-id 7253F2F1-6B56-4BDD-8F97-12E05F85B20A@phlo.org
Whole thread Raw
In response to Re: [PATCH] Negative Transition Aggregate Functions (WIP)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] Negative Transition Aggregate Functions (WIP)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Jan10, 2014, at 19:08 , Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> Kevin Grittner <kgrittn@ymail.com> writes:
>>> The real issue here is that if you are using an approximate data type
>>> and expecting exact answers, you will have problems.
> 
>> That's a canard.  People who know what they're doing (admittedly a
>> minority) do not expect exact answers, but they do expect to be able to
>> specify how to do the calculation in a way that minimizes roundoff errors.
>> The inverse-transition-function approach breaks that, and it does so at a
>> level where the user can't work around it, short of building his own
>> aggregates.
> 
> Although, having said that ... maybe "build your own aggregate" would
> be a reasonable suggestion for people who need this?  I grant that
> it's going to be a minority requirement, maybe even a small minority
> requirement.  People who have the chops to get this sort of thing right
> can probably manage a custom aggregate definition.

So we'd put a footgun into the hands of people who don't know what they're
doing, to be fired for performance's sake, and leave it to the people
who know what they are doing to put the safety on?

best regards,
Florian Pflug



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL
Next
From: Tom Lane
Date:
Subject: Re: new json funcs