Quoting Bojan Smojver <[EMAIL PROTECTED]>:
We could have others - for instance apr_dbd_file_t (for APR_DBD_TYPE_BFILE), which could look something like this:struct apr_dbd_file { apr_file_t *file; /**< file to read the data from */ apr_size_t size; /**< size to read */ apr_off_t offset; /**< offset to read from */ const char *table; /**< table name (used for Oracle) */ const char *column; /**< column name (used for Oracle) */ };
Actually, please disregard this part of my reply. I'll blame it on early morning, although we all know that's not true ;-)
Seriously, for something like this to be useful, databases would need to know how to take an open file descriptor, offset and size and use that as input to execPrepared (and similar). These functions usually expect a pointer to a chunk of memory and size or nul terminated string, so the above probably wouldn't be useful at all.
Which brings me to my reasoning why apr_dbd_blob_t doesn't contain a brigade (one of the proposals that was floating on the list), but rather a flat data pointer and size (in case you were wondering). The caller is in a much better position to control memory allocation issues here and leaving the "flattening" of a brigade to DBD functions can bring about all kinds of unwanted memory allocation effects. In the end, most databases deal with a flat chunk of memory and that's what callers mostly have anyway.
-- Bojan
