Quoting Alex Dubov : > Ok. Here is a patch against webthing's rev 34 (I > assume it's a last one). Yep, that's right. > There's a brief changelog in > the beginning of the file. > > Two warnings, however: > 1. I only use mysql-5 I think Nick wanted to see the driver working with 4.1 as well. I have machines with this version around - it will be trivial to see what doesn't compile. > Also: my patch does not uses is_null and error arrays > (these are set to zero) - instead is_null_value and > error_value are checked in result's BIND structure. OK. As long as segfaults are avoided (which used to be the case until recently with driver from the head and MySQL 5.0), it should be OK. > I also don't have any pre-set bounds on maximum field > length and I don't know what happens if somebody tries > to pass LONG BLOB (the only type which can have > unreasonable size). It's easy to work around long > blobs using SUBSTRING sql statement with offset/size > as parameters, but in general some sort of > truncation/continuation interface is probably needed > (and some interface for mysql_stmt_send_long_data, to > send long data back to db). On the other hand, the > need for such long data in databases is rather limited. I'm a bit worried about things like this: ------------------------------------ (*res)->bind[i].buffer_length = (*res)->res->fields[i].length; [..snip..] data[i] = apr_palloc(pool, sizeof(struct blob_t) + (*res)->bind[i].buffer_length); ------------------------------------ For LONG TEXT, length gets returned as 4294967295 (at least it does with 5.0.21 on my FC5 box), although the actual data is much smaller (there is only about 50 bytes in the field). I don't think we should let the allocator come up with solutions for that one :-) I have to inspect/test the patch in detail, as it also removes some of the segfault fixes that were put in recently (for transactions and prepared statement cleanups). I'll keep you posted... I also wanted to ask about CLIENT_FOUND_ROWS flag (which your patch removes). I used that flag in one of the recent updates to the driver in order to bring MySQL behaviour in line with other DBD drivers. In particular, PostgreSQL/Sqlite3 databases will report that rows have been affected if UPDATE finds a match, regardless of whether the data was the same or not. By default, MySQL will say that 0 rows were affected if data was the same. When the flag is used, this brings MySQL in line with others. Is that something that MySQL users may find problematic? Should we have another option to _open() instead (e.g. flags)? -- Bojan