On Jan11, 2014, at 01:24 , Jim Nasby <j...@nasby.net> wrote: > On 1/10/14, 1:07 PM, Tom Lane wrote: >> Florian Pflug<f...@phlo.org> writes: >>> >On Jan10, 2014, at 19:08 , Tom Lane<t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
