On Jan11, 2014, at 01:24 , Jim Nasby <jim@nasby.net> wrote:
> On 1/10/14, 1:07 PM, Tom Lane wrote:
>> Florian Pflug<fgp@phlo.org> writes:
>>> >On Jan10, 2014, at 19:08 , Tom Lane<tgl@sss.pgh.pa.us> wrote:
>>>> >>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?
>> If I may put words in Kevin's mouth, I think his point is that having
>> float8 sum() at all is a foot-gun, and that's hard to deny. You need
>> to know how to use it safely.
>
> And IMHO if you've got something that's going to produce bad data if you do it
> wrong, I'd rather that the error be as large as possible so that you're more
> likely to discover it and fix it...
To that principle, I agree, I just don't think it applies here. An inverse
transition function greatly *increases* the chance of bogus results for
sum(float). It also breaks some rather natural assumptions that one might
make about sum(float)'s behaviour. For example, sums over single-element
frames current return the one row's value unchanged. That's no longer true
universally true with an inverse transition function. Even for an approximate
type, that's a bid too weird for my taste.
best regards,
Florian Pflug