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