> On Wed, Jan 28, 2009 at 06:32:19AM -0500, John Scoles wrote:
>> > On Tue, Jan 27, 2009 at 08:51:10PM +0100, Peter J. Holzer wrote:
>> >> On 2009-01-27 15:21:55 +0000, Martin Evans wrote:
>> >> > I'm working with DBD::Oracle at the moment and getting a little
>> >> frustrated with
>> >> > integer numbers. I'd like my database returned integers to look
>> like
>> >> integers
>> >> > to Perl but they currently don't until I add 0 to them. Here is the
>> >> problem:
>> >>
>> >> I think this is on purpose. Oracle numbers have a huge precision (38
>> >> decimal digits), so in general you cannot convert them to a perl
>> number
>> >> without losing precision. DBD::Oracle could be smart enough to
>> recognize
>> >> the safe cases (integers with at most 9 (32 bit) resp. 18 (64 bit)
>> >> digits), but AFAIK it isn't. Your best bet is probably explicitely
>> >> binding with an approriate type (SQL_INTEGER).
>> >
>> > That would be the right way to do it, but DBD::Oracle doesn't support
>> > it at the moment.
>>
>> Where would the patch for this go?
>>
>> Patch how SQL_INTEGER is handled on the way out to Perl or add the
>> smarts
>> to DBD::Oracle to see the safe cases??
>
> bind_col() could set the fbh->fetch_func pointer for that column to
> point to a new fetch_func_integer() function. Or something like that.
>
Ok fair enough but how to nasty little part of the safe cases??
Changing from this
char *p = (char*)row_data;
sv_setpvn(sv, p, (STRLEN)datalen)
to something like this
double dnum;
(void) OCINumberToReal(fbh->imp_sth->errhp, (CONST OCINumber *) row_data,
(uword) sizeof(dnum), (dvoid *) &dnum);
sv_setnv(sv, dnum);
John
> Tim.
>
