01.11.2012 11:59, Mark Rotteveel wrote: > As far as I know the CAST behavior in dialect 3 conforms to the SQL > standards, while those in dialect 1 don't. I don't think that > non-conformance is a good reason to stick to Dialect 1.
It's not about CAST per se, it's about multiplication and division. CAST is just a workaround to prevent the scale from growing in intermediate calculation results thus forcing the [limited] precision to overflow. E.g.: num_18_4 * num_18_2 * num_18_2 -- result is num(18, 8) i.e. 10 digits for the integral part It may overflow even if you're assigning the result to a num(18, 2) target to round it and have 16 digits available for the integral part. vs cast(num_18_4 * num_18_2 as num(18, 2)) * num_18_2 -- result is num(18, 4) i.e. 14 digits for the integral part Chances for an overflow are significantly less. Dmitry ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
