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. Tim. On Fri, Jun 13, 2003 at 12:37:27PM +1000, Mike Battersby wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Content-Type: text/plain; charset=us-ascii > > > Tim Bunce wrote: > > On Thu, Jun 12, 2003 at 05:17:17PM +1000, Mike Battersby wrote: > > > Is it preferable to support LongReadLen and LongTruncOk, or just to return > > > the entire field? > > And if you have table full of multi-gigabyte video clips? > > Don't select them? I'm not sure -- what's the status of blob_read in DBI > (definitely not supported in my current code)? Just getting the first part > of a multi-gigabyte long video clip doesn't seem helpful at all. > > > Note that the DBI spec does not mandate a default value. > > You're quite free to set it to the maximum value it'll hold. > > Ok, good point. :) I'll see how this holds up with respect to the Ingres > limits but it seems like the way forward. > > Henrik Tougaard wrote: > > I've been using all my tuits in trying to port to the OpenAPI (so that the > > I haven't looked at it myself, what's the advantage? It seems like > rewriting with OpenAPI would be a complete re-implementation. Maybe a > separate DBD::OpenIngres would make sense? > > > Send it to me, and I promise^Wwill do my best tp get it out fast. > > Now that it seems clear the correct approach is to set LongReadLen to be > the maximal value by default and support the DBI spec, I've bit of work > to do to port the dynamic memory allocation code from my other branch. > Hopefully I'll have something for you early next week -- would you prefer > a unified diff, tarball, ... ? > > If it'd be helpful I could probably separate out the binary data type > support from the long support. It'd be a bit of work, but if it helps > get a new DBD::Ingres out faster I'd be prepared to spend the effort. > > - Mike > > - -- > Mike Battersby <[EMAIL PROTECTED]> The University of Melbourne > Fetch my pgp key from: http://ariel.ucs.unimelb.edu.au/~mib/pgpkey.txt > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.4 (SunOS) > Comment: Exmh version 2.2 06/23/2000 > > iD8DBQE+6Tjn5nQGV2rjQWARApokAKCgE8f0eCOikK8EKxqScJb4eyTHQwCfVE/W > 996NaYZLimLvm/JSsnxg1/I= > =sGCE > -----END PGP SIGNATURE----- >
