> 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. I think we need to straighten this out. Nick basically proposes to use structure similar to MYSQL_BIND one - you grab the structure, fill it with data (type, length) and pass it to the dbd (I saw that Nick currently suggests to append only type tag). I'm thinking about different approach - you have your data (including bucket or bb for binaries); you have format specifier; from here everything works just like with printf - if you push pointer incompatible to specifier, it's most likely a crash.
There's nothing in p(v)select that prevents it from using generic pointers. People are doing this for years with printf and it never was a problem. Another way to view this: specifier is a type tag, but there's no need to carry it all over as there's no easy way for user to act upon it. It's not like type of any specific field is going to change suddenly and apr_dbd is not implemented in Scheme (may be it should be). I'm using this approach for a while now and it works rather well. Of course, back-ends should not be obligated to support anything beside strings, but it will be nice for them to actively reject specifiers they don't support. The symmetric case, with get_entry implemented in a scanf style is not difficult to implement, at least with mysql. libmysqlclient does all the needed conversions itself (I don't know about other databases, but they can honour only strings and reject everything else, if they want to). Additional advantage here is movement of numbers - you can skip allocation and simply fetch into user supplied pointers. Even better: this approach makes get_row unneeded, simplifying typical db access. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
