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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
