Thinking about this some more...
The origin of LongReadLen is related to the problem of not knowing in advance how long the longest LONG selected will be. So for drivers which need to pre-allocate buffers for the db api to fetch into there needed to be some way to define what size to use.
If your db api provides a way to dynamically size buffers for LONGs then the original motivation for LongReadLen goes away.
Then you're left with applications that might want to use LongReadLen to just read the first portion of a LONG without having gigabytes sent from the server to the client. (First page or so of a long text, first frame of a video clip, etc.) For these purposes LongReadLen is still of use.
I propose to change LongReadLen from an integer to an SV (perl scalar) that can be set to undef. Undef would mean "read entire value if possible". I would probably also change the DBI default to be undef.
Drivers that still need LongReadLen in order to pre-allocate a fixed size buffer should default LongReadLen to a suitable value.
Sounds reasonable to me. DBD::Informix has never supported LongReadLen because the API it uses does the memory allocation dynamically -- and I disliked the semantics. The revised semantics and default are acceptable; if agreed elsewhere, I'd be prepared to add support for it to DBD::Informix in due course.
--
Jonathan Leffler ([EMAIL PROTECTED], [EMAIL PROTECTED]) #include <disclaimer.h>
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/
