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-
