Tom Lane wrote:
I wrote:
...
Now it's unlikely that real-world applications are going to be as
dependent on the speed of div_var for long inputs as numeric_big is.
And getting the right answer has to take priority over speed anyway.
Still this is a bit annoying. Anyone see a way to speed it up, or
have another approach?
regards, tom lane
+1 for the change from me.
We use PostgreSQL for financial accounting stuff, including plpgsql
triggers and functions etc. And we use numeric for all that. I always
thought that numeric division was exact! :-) I never saw problem,
perhaps because we round to very few digits, but well.
Please apply this patch. I can accept the performance drop, as long as
there won't be bad surprises with correctness.
Best Regards
Michael Paesold
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
