On Wed, Jan 28, 2009 at 10:30:49AM -0500, John Scoles wrote:
> >> >>
> >> >> 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??

Eh?

Tim.

> 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.
> >
> 
> 

Reply via email to