MySQL AB :: MySQL 3.23, 4.0, 4.1 Reference Manual :: D.3.24 Changes in release 3.23.36 (27 March 2001)

D.3.24. Changes in release 3.23.36 (27 March 2001)

Fixed a bug that allowed use of database names containing a ‘.’ character. This fixes a serious security issue when mysqld is run as root. (CVE-2001-0407)
Fixed bug when thread creation failed (could happen when doing a lot of connections in a short time).
Fixed some problems with FLUSH TABLES and TEMPORARY tables. (Problem with freeing the key cache and error Can't reopen table....)
Fixed a problem in InnoDB with other character sets than latin1 and another problem when using many columns.
Fixed bug that caused a core dump when using a very complex query involving DISTINCT and summary functions.
Added SET TRANSACTION ISOLATION LEVEL ...
Added SELECT ... FOR UPDATE.
Fixed bug where the number of affected rows was not returned when MySQL was compiled without transaction support.
Fixed a bug in UPDATE where keys weren't always used to find the rows to be updated.
Fixed a bug in CONCAT_WS() where it returned incorrect results.
Changed CREATE ... SELECT and INSERT ... SELECT to not allow concurrent inserts as this could make the binary log hard to repeat. (Concurrent inserts are enabled if you are not using the binary or update log.)
Changed some macros to be able to use fast mutex with glibc 2.2.

User Comments

Posted by Mike Wexler on June 17 2002 3:39pm

The documentation on $sth->{rows} should talk
about the difference between rows matched and
rows changed.

For example

UPDATE foo SET bar=1 WHERE uniqueKey=1

Could set rows to 0 or 1 even if there was
exactly one record with uniqueKey=1 if the field
bar was already 1 $sth->{rows} would be zero
otherwise $sth->{rows} would be 1. Also a pointer
to how to get the other piece of information
(rows matched) would be nice.

Posted by Begrudged Biker Mouse on June 17 2002 3:39pm

[Delete] [Edit]

Some of the field names listed there seem to be incorrectly cased. For example, using the current DBI::mysql, after a $sth=$dbh->prepare("LISTFIELDS users"); $sth->execute();, $sth->{TYPE} is set (as an ARRAYREF of types) but not $sth->{type}. Readers should probably consult the DBI docs if some fields turn up undef when typed in the cas mentioned here.

Add your own comment.