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