Peter J. Holzer - [EMAIL PROTECTED] wrote:
> On 2008-03-14 09:50:15 +0000, [EMAIL PROTECTED] wrote:
>> This is more for the archives than anything as there is a workaround.
>>
>> When inserting 1234567890.123456 into a decimal(16,6) column, the
value stored is 1234567890.123460
>
> The value 1234567890.123456 is not exactly representable in a perl
> numeric scalar (assuming 64 bit double, which is a reasonable
perl -V gives doublesize=8
> assumption). The nearest representable approximation is
> 1234567890.12345600128173828125.
>
> However, rounding that to 6 digits after the comma is 1234567890.123456,
> so I don't see a reason for the wrong rounding. It looks more like if
> it's rounded to 5 digits instead of 6.
Time::HiRes docs say
"What is going on is that the default floating point
format of Perl only outputs 15 digits. In this case
that means ten digits before the decimal separator and
five after"
> In this case the scalar is a string instead of a number. I don't know
> the internals of DBD::mysql, but I would expect that it is also passed
> as a string to the server, which then stores it "as is" (converting to
> the internal decimal type of course, but that's just some
> bit-twiddling).
I believe the default type is SQL_VARCHAR.
I did try changing that via bind_param to SQL_DECIMAL (type 3 which
DBD::mysql reports as being the column type) but it made no difference.
>> Is this expected behaviour or should DBD::mysql automagically do the
right thing?
>
> I would expect rounding errors when passing numeric scalars to "decimal"
> types in general, but not in this case - that should be handled
> correctly (because it can).
I wasn't sure it could be or not. Unless the driver knows the precision
of course. It's probably a good idea to put something in the docs, a la
Time::HiRes.
John
