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. The constraint this would pose on the float4 and float8 implementations is that it be possible to use their transition and final functions in a custom aggregate declaration while leaving off the inverse function; or, if that combination doesn't work for some reason, we have to continue to provide the previous transition/final functions for use in user aggregates. Suitable documentation would be needed too, of course. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers