Bug #16668 | "varchar binary" being stripped of "binary" option on MySQL 5 | ||
---|---|---|---|
Submitted: | 20 Jan 2006 12:45 | Modified: | 30 Jan 2006 9:33 |
Reporter: | Anders Henke | Email Updates: | |
Status: | Not a Bug | Impact on me: | |
Category: | MySQL Server | Severity: | S2 (Serious) |
Version: | 4.0.25 and 5.0.18 | OS: | Linux (Linux) |
Assigned to: | CPU Architecture: | Any |
[20 Jan 2006 12:45]
Anders Henke
[29 Jan 2006 15:31]
Jorge del Conde
Thanks for your bug report: CREATE TABLE `foo` ( `t` varchar(255) character set latin1 collate latin1_bin default NULL ) ENGINE=MyISAM DEFAULT CHARSET=latin1;
[30 Jan 2006 9:33]
Sergei Golubchik
This is actually expected behaviour. In 5.0 "varchar(N) binary" is as close to 4.0 "varchar(N) binary" as possible - it also results in variable, yet case-sensitive field. "binary" is not ignored, it forces the collation to be binary - see SHOW CREATE TABLE output, in Jorge's reply - the collation is "latin1_bin", which, precisely, means case-sensitive comparison. varbinary(N) is different, it means the column is just a set of bytes, no character set attached. For example, UPPER() and LOWER() doesn't work on varbinary columns. (in fact, in the early 4.1 versions, we did map varchar(N) binary to varbinary(N), it was changed later to mean binary collation, after we got numerous complains that UPPER/LOWER stopped working)