23.03.2013, 16:49, "Vadim Zeitlin" <[email protected]>: > On Fri, 22 Mar 2013 14:40:36 +0000 Mateusz Loskot <[email protected]> wrote: > > ML> > The "endOfRowSet" fix is perfectly safe to apply, it can't break > anything > ML> > because it changes nothing if execute() is called only once and if it's > ML> > called twice or more times, currently it doesn't work at all so anything > ML> > else can only be an improvement. > ML> > ML> I see. > > This was indeed correct.
Ok, shouldn't it behave the same way for any other backend? May be the test-case you've added is better placed in common tests? > > ML> > The "s/unsigned/int/" fix for SQL_LONG is slightly more risky but, > still, > ML> > right now you simply get completely wrong values when reading from the > ML> > database (something like 4953.956 when the database contains -0.0013), > so > ML> > IMO it would still be better to apply it rather than not do it because > ML> > silently reading wrong data is one of the worst things that can happen > in > ML> > a database library. > > The above was correct too, in the "more risky" part. It turned out that > this fix did break Firebird tests[1] and that "unsigned" was used here to > work around the incorrect result when we casted 4000000000 (which is > greater than INT_MAX on 32 bit systems) to int and then to unsigned long > which could be 64 bits, yielding a wrong value. > > However I don't believe the original fix by Viacheslav (see 4c3cb629) > was the right way to do it, it only hid the problem but didn't solve it. > Using SQL_LONG for "unsigned long" simply can't work on LP64 systems > because SQL_LONG is just not big enough. So the real fix is to use > SQL_INT64 here and this is as simple as creating the column of right type > in the test database and this is what my fix[2] does. And with that fix > applied, the original commit fixing reading doubles still works and doesn't > break the tests any more. > Sorry, my bad. In Firebird a column of decimal(9,0) is represented by 32-bit integer type internally, but still it is not suppsed to store 4000000000 correctly. However, fbclient API doesn't give a warning about this, while the console client does. SQL> create table test_types2 ( col1 decimal(9,0) ); SQL> insert into test_types2(col1) values(4000000000); Statement failed, SQLSTATE = -802 arithmetic exception, numeric overflow, or string truncation SQL> -- Best regards, Viacheslav Naydenov. ------------------------------------------------------------------------------ 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_d2d_mar _______________________________________________ soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
