Alexander M. Turek wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi devels,
it looks as if MySQL has silently deprecated the BINARY sttribute in MySQL 4.1. If you create a CHAR(3) BINARY field, it becomes CHAR(3) CHARACTER SET latin1 COLLATE latin1_bin.
Old [VAR]CHAR BINARY fields are mapped to [VAR]BINARY. This leads us to various incompatibilities:
- We don't have these fields in our list of possible table fields and I
don't know if MySQL 3.23.32 supports the syntax, so adding them generally wouldn't we a good idea, imho.
I just merged some changes. I add BINARY and VARBINARY column types dynamically to $GLOBALS['cfg']['ColumnTypes'] on MySQL 4.1.x.
- tbl_properties_structure.php recognizes these fields correctly as
binary fields, but strips off the string "BINARY", so "VARBINARY(20)" becomes "var(20)" and even worse "BINARY(20)" becomes "(20)".
fixed.
- when trying to alter these fields, both are recognized as VARCHAR
BINARY, which is dangerous because if we just want to change the size for instance, they get changed to "VARCHAR CHARACTER SET latin1 COLLATE latin1_bin"...
fixed
- The binary column in tbl_properties_structure is superfluous, imho.
And so is the BINARY entry in the list of field attributes.
You mean the Attributes column? The BINARY entry is superfluous only under MySQL 4.1.x, right?
- The parser does not recognize BINARY as column type.
fixed
Marc
Here's a simple table for reproducing the problem:
CREATE TABLE `binarytest` ( `one` binary(3), `two` varbinary(10) )
Alexander M. Turek