On Jan10, 2014, at 19:08 , Tom Lane <t...@sss.pgh.pa.us> wrote:
> I wrote:
>> Kevin Grittner <kgri...@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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to