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

"Greg Sabino Mullane" <[email protected]>
Newsgroups gmane.comp.lang.perl.modules.dbi.sybase.devel
Message-ID <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----                                 
Hash: RIPEMD160                                                    


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

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?

- --
Greg Sabino Mullane [email protected]
End Point Corporation
PGP Key: 0x14964AC8 200910261039
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkrltQwACgkQvJuQZxSWSsgXkACglr89gAmjiRJEluR5846rATvb
luEAoKsaP7MdQEB3pjUCjh2xYvd2V8D2
=J3V0
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.