MR> The SQL Standard - intentionally - does not specify behavior for MR> division. When dialect 3 was implemented, Borland opted to use the same MR> rules as the SQL standard specifies for multiplication.
Thanks Borland <g> MR> I'm not so sure this is so easy to do. You either have additional space MR> requirements for the calculation, or you lose precision by converting to MR> a double precision for intermediary results. I'm sure there is no easy solution, otherwise, it would probably be already implemented. MR> I don't think we should introduce yet another configuration option for MR> backwards compatibility, nor have the parser apply some fuzzy logic MR> which will only lead to hard to diagnose bugs. I'm hearing... MR> I'd prefer if anything is changed, this is not done without resorting MR> hackish solutions that will just create another set of confusion, but MR> instead by using generally accepted arbitrary precision decimal MR> calculation rules from standards like ANSI X3.274-1996 or IEEE 754R, or MR> alternatively by looking at what Java's BigDecimal does, or maybe what MR> other database engines do (although there it seems as confusing as with MR> Firebird). Idea is to discuss available solutions to find the better (possible to be implemented) one. I never imposed any solution, and I'm sure it will not be me who will hit the hammer. I leave this for the core developers. []s Carlos http://www.firebirdnews.org FireBase - http://www.FireBase.com.br ------------------------------------------------------------------------------ Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing mobile app experiences with Intel(R) XDK. Use one codebase in this all-in-one HTML5 development environment. Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
