apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@rexursive.com>
Subject Re: DBD: Prepared statements, BLOBs etc.
Date Mon, 15 Jan 2007 23:13:05 GMT
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).


View raw message