MySQLdb select

Sibylle Koczian Sibylle.Koczian at Bibliothek.Uni-Augsburg.de
Tue Aug 10 07:39:07 EDT 2004


Sibylle Koczian schrieb:
> Andy Todd schrieb:
> 
>> It's a bug. I think it is a bug in MySQL. I'm using 4.0.18 on Debian 
>> and an interactive session shows the problem;
>>
[snip]

>> Ta-da. Of course, this may have already been notified to MySQL AB, I'd 
>> check their web site (http://www.mysql.com) or try one of their 
>> mailing lists.
>>
> Will do. Thank you. I never thought of trying this directly in MySQL, 
> always took it for a problem between MySQL and Python. I'll check the 
> MySQL newsgroup first, as it's in German.
> 
Not really a bug, possibly no very good design decision (not new with 
MySQL). From the manual:

"13.1.3 Comparison Functions and Operators
[snip]
MySQL compares values using the following rules:
[snip]
     * If one of the arguments is a TIMESTAMP or DATETIME column and the 
other argument is a constant, the constant is converted to a timestamp 
before the comparison is performed. This is done to be more 
ODBC-friendly. Note that the is not done for arguments in IN()! To be 
safe, always use complete datetime/date/time string when doing comparisons."

If a date column is treated the same way, it's clear: "=" compares the 
date column with a timestamp with time part 0 and gets true; IN compares 
the date with a string containing '00:00:00' and gets false.

Regards,
Koczian




More information about the Python-list mailing list