Re: DBD::Oracle, Support binding of integers so they are returned as IVs

Greg Sabino Mullane wrote:
> 
>> I could do what DBD::Pg does here (and have to verify it works) but
>> Oracle integers can be very large - too big to fit in an IV in some
>> cases.                                                             
> 
> Ah yes, I forgot that Oracle doesn't really have an integer type.
> 
>> I think the only person who knows if an integer is small enough
>> to fit in an IV is the person calling bind_col and in any case, my
>> situation is in fact that some of the database integers I need back as
>> strings and some I want as integers. As a result, I think it is
>> necessary to support the TYPE attribute to bind_col.
> 
> Sounds like a foot gun. What happens when the type is declared as int, but
> they send back 999999999999? Wouldn't the value get silently changed
> to 2147483647? A way around that is to have the driver check the size
> to see if it will fit in as IV, but at that point, you don't need the
> user-specified casting anymore, perhaps just a separate flag, e.g.
>
> $dbh->{ora_return_iv_when_possible} = 1;

I was never suggesting any integer would be silently changed - why would
anyone do that.

Doing things automatically won't help me as I only want integers back
for some of the columns. Also, I would not want an IV back for a small
integer in row N and then a string back for a large integer in row N+1
(I'd rather have an error). DBI already defines a TYPE on bind_col and
if it was implemented it could be generally useful as well as useful to me.

> Frankly, it sounds like we're doing a lot of smashing of square pegs into
> round holes to make JSON::XS happy: maybe it's better to look for a solution
> on that end at this point?

I cannot say why you changed DBD::Pg for JSON::XS but I can say why I
want integers back from Oracle instead of strings when I ask for
integers and the column is an integer. I don't think it is square pegs
into round holes.

I don't maintain DBD::Oracle but would have been happy to submit any
patch back for consideration. I was only looking for a push in the right
direction before implementing and even if the consensus is that it is a
waste of time it won't stop me implementing it myself as I need it.
However, I'd rather not do that as I am already maintaining 4 other
changes to DBD::Oracle until at least the next DBD::Oracle is released.

Martin
-- 
Martin J. Evans
Easysoft Limited
http://www.easysoft.com