Quoting Alex Dubov <oakad@yahoo.com>:

> 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