On 12/14/2013 05:00 PM, Tom Lane wrote:
> This consideration also makes me question whether we should apply the
> method for NUMERIC. Although in principle numeric addition/subtraction
> is exact, such a sequence could leave us with a different dscale than
> is returned by the existing code. I'm not sure if changing the number of
> trailing zeroes is a big enough behavior change to draw complaints.
If we're going to disqualify NUMERIC too, we might as well bounce the
feature. Without a fast FLOAT or NUMERIC, you've lost most of the
target audience.
I think even the FLOAT case deserves some consideration. What's the
worst-case drift? In general, folks who do aggregate operations on
FLOATs aren't expecting an exact answer, or one which is consistent
beyond a certain number of significant digits.
And Dave is right: how many bug reports would we get about "NUMERIC is
fast, but FLOAT is slow"?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com