On Mon, 2007-01-15 at 14:37 -0800, Chris Darroch wrote: > For binary BLOB data, that strlen() is going to be a problem.
Yep, that's right. And for the CLOBs it is going to be inefficient, if those things are big. That's why we can go with an approach that, in character mode, encodes both BLOB and CLOB as length:payload. In binary mode, we can just pass this value in apr_datum_t. In both cases, no strlen() would be needed any more. Thanks for confirming this. > At the very least, a way of knowing the length of binary data is > required. Beyond that, it looks like Oracle documents a number of > limitations on this approach: > > http://www.stanford.edu/dept/itss/docs/oracle/10g/appdev.101/b10779/oci05bnd.htm#428395 > > Although it's not mentioned, my own guess is that there are performance > reasons for using LOB locators as well, but that's just a guess. > The issues I suspect would trip users up would be the ones that sometimes > impose a 4 KB limit on the data, depending on the particulars of the > SQL statement. The implicit use of temporary tables might be a surprise > too, I suppose. Yeah, we can sure use LOB locators if that's more efficient. Thanks for the pointers. I was actually wondering about the need to pass the name of the table and the name of column to p[b]query/select, which was the bit that wasn't clear to me. I just can't see the need for that, after my brief reading of OCI documentation. Which would then enable us to use apr_datum_t for passing binary BLOB/CLOB data into pbquery/select, instead of inventing yet another structure and a set of functions to deal with it (as it would be opaque). -- Bojan
