apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Donovan <donov...@bellatlantic.net>
Subject Some dbd driver questions
Date Sat, 24 Mar 2007 15:31:07 GMT
I've been working on an ODBC dbd driver, and I have a few questions 
about how LOBs are supposed to be returned as bucket brigades.

Looking at the Oracle driver, it appears that the caller creates the 
brigade which is passed as an argument to apr_dbd_datum_get.

If the LOB contains no data, the Oracle driver inserts an EOS bucket 
into the brigade, but I don't see that an EOS bucket is ever inserted 
when when the bucket read function finally reaches the end of the data.

What is supposed to happen here?  If the caller really does pass an 
existing brigade - shouldn't the driver presume it already has an EOS 
bucket, as well as other kinds of data or metadata buckets in it?

The handling of NULL (SQL NULL values vs. "C" NULL pointers) is not 
really clear.  I've been setting the return pointer argument to 
_get_entry/_datum_get to NULL to indicate an SQL NULL column value for 
other data types - but this doesn't seem like the right thing to do for 
a pointer to an existing bucket brigade.

Inserting an empty bucket wouldn't distinguish between a bona-fide SQL 
NULL and a LOB which contains zero-length data.

Finally, Most of the non-binary functions have new "b"inary equivalents:

   There is a _pbselect and a _pvbselect - but not a simple _bselect.

Is it intentional that there is no un-prepared binary select, or was 
this just an oversight?  One-shot (i.e. runtime generated SQL) 
statements don't benefit much from being prepared and then only used 
once.  A _bselect function would be useful.

Thanks for any advice you can give me.

-tom-





Mime
View raw message