Bug #720 | Select Problem | ||
---|---|---|---|
Submitted: | 25 Jun 2003 8:11 | Modified: | 27 Jun 2003 10:25 |
Reporter: | Giovanni Monferdini | Email Updates: | |
Status: | Not a Bug | Impact on me: | |
Category: | MySQL Server: InnoDB storage engine | Severity: | S2 (Serious) |
Version: | 4.1 alpha | OS: | Linux (linux RH 7.1) |
Assigned to: | Ramil Kalimullin | CPU Architecture: | Any |
[25 Jun 2003 8:11]
Giovanni Monferdini
[27 Jun 2003 2:29]
Heikki Tuuri
Hi! Looks like you have to use the CAST(hexnumber AS CHAR) function to force MySQL to treat the hex string as a character string. Then it works. But the documentation at http://www.mysql.com/doc/en/Hexadecimal_values.html claims that you would not need to use the CAST() function. The behavior is the same for MyISAM and InnoDB tables. Regards, Heikki mysql> show create table s10; +-------+----------------------------------------------------------------------- -------------------------------------------------------------------------+ | Table | Create Table | +-------+----------------------------------------------------------------------- -------------------------------------------------------------------------+ | s10 | CREATE TABLE `s10` ( `a` char(9) binary NOT NULL default '', `b` char(9) default NULL, PRIMARY KEY (`a`), KEY `b` (`b`) ) TYPE=InnoDB | +-------+----------------------------------------------------------------------- -------------------------------------------------------------------------+ 1 row in set (0.00 sec) mysql> insert into s10 values (0x111213, 0x111213); Query OK, 1 row affected (0.00 sec) mysql> select * from s10 where a > CAST(0x11 AS CHAR); Empty set (0.00 sec) mysql> select * from s10 where a > CAST(0x110000 AS CHAR); +-----+------+ | a | b | +-----+------+ | | | +-----+------+ 1 row in set (0.00 sec) mysql> select * from s10 where a = CAST(0x110000 AS CHAR); Empty set (0.00 sec) mysql> select * from s10 where a < CAST(0x110000 AS CHAR); Empty set (0.00 sec) mysql> select * from s10 where b > CAST(0x110000 AS CHAR); +-----+------+ | a | b | +-----+------+ | | | +-----+------+ 1 row in set (0.00 sec) mysql> select * from s10 where b = CAST(0x111213 AS CHAR); +-----+------+ | a | b | +-----+------+ | | | +-----+------+ 1 row in set (0.00 sec) mysql> select * from s10 where b > CAST(0x111213 AS CHAR); Empty set (0.00 sec)
[27 Jun 2003 3:00]
Ramil Kalimullin
Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.mysql.com/documentation/ and the instructions on how to report a bug at http://bugs.mysql.com/how-to-report.php First of all, you should correct a typo in your query: should be '... PE_TAB='SAL.01'...' instead of '...PE_TAB='SAL.1'...'. Second: expression '' > 0x19 is FALSE. '' is empty string, 0x19 is one-char string, so it's greater than '', so it's expected behavior.
[27 Jun 2003 10:25]
Heikki Tuuri
Ramil, I tested the behavior on 4.0.14 and looks like there MySQL treats the hex number as an integer in a '<' comparison and converts the COLUMN to an integer, too. The conversion produces value 0 for the column. But a pure SELECT 0x7865 treats the hex string as a string! In 4.1.1 MySQL treats the hex number as a string in both contexts. The docs claim that "In numeric context these act like an integer (64-bit precision). In string context these act like a binary string where each pair of hex digits is converted to a character:" Conclusion: you have use an explicit typecast in 4.0 to be sure what data type the hex string gets internally. The docs should warn users that the 'context' of a hex string is determined by complicated rules. Regards, Heikki heikki@hundin:~/mysql-4.0/client> mysql test Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 2 to server version: 4.0.14-debug-log Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> show create table s10; +-------+----------------------------------------------------------------------- -------------------------------------------------------------------------+ | Table | Create Table | +-------+----------------------------------------------------------------------- -------------------------------------------------------------------------+ | s10 | CREATE TABLE `s10` ( `a` char(9) binary NOT NULL default '', `b` char(9) default NULL, PRIMARY KEY (`a`), KEY `b` (`b`) ) TYPE=MyISAM | +-------+----------------------------------------------------------------------- -------------------------------------------------------------------------+ 1 row in set (0.00 sec) mysql> insert into s10 values ('abc', 'abc'); Query OK, 1 row affected (0.01 sec) mysql> select * from s10 where a > 0x10; Empty set (0.00 sec) mysql> select * from s10 where a > CAST(0x10 AS CHAR); +-----+------+ | a | b | +-----+------+ | abc | abc | +-----+------+ 1 row in set (0.00 sec) mysql> BUT: mysql> select 0x4344; +--------+ | 0x4344 | +--------+ | CD | +--------+ 1 row in set (0.00 sec) mysql> " MySQL supports hexadecimal values. In numeric context these act like an integer (64-bit precision). In string context these act like a binary string where each pair of hex digits is converted to a character: mysql> SELECT x'4D7953514C'; -> MySQL mysql> SELECT 0xa+0; -> 10 mysql> SELECT 0x5061756c; -> Paul In MySQL 4.1 (and in MySQL 4.0 when using the --new option) the default type of of a hexadecimal value is a string. If you want to be sure that the string is threated as a number, you can use CAST( ... AS UNSIGNED) on the hexadecimal value. The x'hexstring' syntax (new in 4.0) is based on standard SQL and the 0x syntax is based on ODBC. Hexadecimal strings are often used by ODBC to supply values for BLOB columns. You can convert a string or a number to string in hexadecimal format with the HEX() function. "