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.
