On Wed, Jun 03, 2009 at 10:49:05PM -0500, David Nicol wrote: > trial and error brings results, but seems sub-optimal. > > Specifally, I tried lots of other things before finding that > SQL_DECIMAL allows 9223372036854775807 to enter into Perl as a string > rather than as 9.blahblahblahe+18. (useing sqlite.)
I'm (pleasantly) surprised specifying a data type for bind_col made any difference at all :) > Are these things driver-specific or are there sane fallbacks? For > instance, SQL_BIGINT might have gotten mapped to SQL_DECIMAL for this > driver. They are driver specific. Most drivers just ask the db api for a string and then stuff the string into an SV. Some ask the db api for the type of the column and then make at least an int/float/string distinction. Few support specifying a data type for bind_col. I think it would be reasonable for SQL_DECIMAL to mean 'a string of digits not in exponential format'. For SQL_BIGINT it would be apropriate for it to mean a true 64-bit int on machines where perl was built with support for 64-bit ints (IVs). On machines where 64-bit IVs are not available it's more tricky. Falling back to SQL_DECIMAL-like behaviour is probably best. Anyone want to draft up a doc patch to cover this? Tim.
