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 Wed, 06 Sep 2006 23:16:27 GMT
Quoting Bojan Smojver <bojan@rexursive.com>:

> 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.


View raw message