Thank you for the explanation. The test is looking to see that the scalar does not look like a string because it wants to behave like a number because it was a number in the database. The test is simply ensuring the scalar was either created with sv_setiv or sql_type_cast_svpv was run on it.

Before sql_type_cast_svpv or DBDs like DBD::ODBC (here) set the scalar with sv_setiv the scalar looks like a string then you have to add 0 to all your numbers retrieved from the database before passing them to modules like JSON::XS or they will be turned into "NNN" instead of NNN. Another example was people doing select a_int, b_int from table then performing a_int & b_int which gives the wrong answer unless you add 0 to them first. See http://search.cpan.org/~timb/DBI-1.620/DBI.pm#sql_type_cast and various discussions on dbi-dev mailing list.