apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@rexursive.com>
Subject Re: LONGs and LOBs [Was: improved error reporting for apr_dbd_mysql.c]
Date Thu, 01 Jun 2006 02:45:35 GMT
Quoting Alex Dubov <oakad@yahoo.com>:

>> Second, instead of paying attention to various
>> letters like %B, %L, %s
>> and so on, which come from when the statement was
>> prepared, we ignore
>> them in p[v]bquery/bselect, but we pass
>> apr_dbd_entry_t ** instead of
>> const char ** into the function. Then we have both
>> the type/length
>> figured out explicitly and can pass binary data in
>> safely, without the
>> need to do dubious strlen()'s.

I was actually referring there to the input arguments of prepared  
statements, not values pulled out of select.

> void* apr_dbd_get_entry_as(apr_dbd_type_t type)
> or may be even
> int apr_dbd_get_entries(char *format, ...)

Right. But we're still no better off - we still need to be able to  
store all kinds of types in something we understand with just APU DBD.

The underlying problem is that we don't have a way of returning binary  
data (i.e. buffer + length or something even smarter, like a brigade)  
from get_entry(). Nick's little structure solves that problem for  
getting the entries out of select, because it tells us all we need to  
know. Your solution goes a step further and attempts to cast things as  
well for the caller, but will still need something (or many of those)  
known to the caller on APU DBD level to store all kinds of stuff.

The other problem is of input arguments for prepared statements, where  
again we don't have support for anything but zero terminated strings  
at the moment. With a generic structure that Nick suggested, we could  
solve that problem too.


View raw message