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