| List: | Falcon Storage Engine | « Previous MessageNext Message » | |
| From: | Ann W. Harrison | Date: | February 18 2009 7:29pm |
| Subject: | Re: Patch for bug#42208 | ||
| View as plain text | |||
Kevin Lewis wrote: > > Well, here is the MySQL (read MyISAM) implemetation; > > 1) BINARY fixed length fields are always padded out to the fixed length. > Thus for a BINARY(5) column; 0x00, 0x0000, 0x000000 and 0x00000000 are > all equal because they are all stored and sorted as 0x0000000000. > > 2) VARBINARY fields must take into account the actual length. > Thus for a VARBINARY column; 0x00, 0x0000, 0x000000 and 0x00000000 are > all different and sorted by length. > And if you compare a binary with a varbinary? Are constants fixed or varying? I realize that the MyISAM implementation is definitive by definition, but I wish it had been better thought out. At least with strings, 'a' = 'a', regardless of whether they're stored as char(20) or varchar(20). Vlad's suggestion for a reimplementation of multi-segment keys with suffix compression solves the problem and lets us work like MyISAM. In spite of that, it seems like a good idea. Cheers, Ann
| Thread | ||
|---|---|---|
| • Patch for bug#42208 | Lars-Erik Bjørk | 16 Feb |
| • RE: Patch for bug#42208 | Vladislav Vaintroub | 16 Feb |
| • RE: Patch for bug#42208 | Vladislav Vaintroub | 16 Feb |
| • Re: Patch for bug#42208 | Jim Starkey | 16 Feb |
| • RE: Patch for bug#42208 | Vladislav Vaintroub | 16 Feb |
| • Re: Patch for bug#42208 | Jim Starkey | 16 Feb |
| • RE: Patch for bug#42208 | Vladislav Vaintroub | 16 Feb |
| • Re: Patch for bug#42208 | Lars-Erik Bjørk | 17 Feb |
| • Re: Patch for bug#42208 | Kevin Lewis | 17 Feb |
| • Re: Patch for bug#42208 | Ann W. Harrison | 18 Feb |
| • Re: Patch for bug#42208 | Ann W. Harrison | 18 Feb |
| • Re: Patch for bug#42208 | Ann W. Harrison | 18 Feb |
| • Re: Patch for bug#42208 | Kevin Lewis | 18 Feb |
| • Re: Patch for bug#42208 | Ann W. Harrison | 18 Feb |
| • Re: Patch for bug#42208 | Kevin Lewis | 18 Feb |
| • RE: Patch for bug#42208 | Vladislav Vaintroub | 18 Feb |
| • RE: Patch for bug#42208 | Vladislav Vaintroub | 18 Feb |
| • Re: Patch for bug#42208 | Kevin Lewis | 18 Feb |
| • RE: Patch for bug#42208 | Vladislav Vaintroub | 18 Feb |
| • RE: Patch for bug#42208 | Vladislav Vaintroub | 18 Feb |
| • Re: Patch for bug#42208 | Jim Starkey | 18 Feb |
| • RE: Patch for bug#42208 | Vladislav Vaintroub | 18 Feb |
| • Re: Patch for bug#42208 | Jim Starkey | 18 Feb |
| • RE: Patch for bug#42208 | Vladislav Vaintroub | 18 Feb |
| • RE: Patch for bug#42208 | Vladislav Vaintroub | 18 Feb |
| • Re: Patch for bug#42208 | Ann W. Harrison | 18 Feb |
| • RE: Patch for bug#42208 | Vladislav Vaintroub | 18 Feb |
| • Re: Patch for bug#42208 | Jim Starkey | 18 Feb |
| • Re: Patch for bug#42208 | Ann W. Harrison | 18 Feb |
| • Re: Patch for bug#42208 | Ann W. Harrison | 18 Feb |
| • Re: Patch for bug#42208 | Ann W. Harrison | 18 Feb |
| • RE: Patch for bug#42208 | Vladislav Vaintroub | 18 Feb |
| • Re: Patch for bug#42208 | Ann W. Harrison | 18 Feb |
| • Re: Patch for bug#42208 | Kevin Lewis | 18 Feb |
| • Re: Patch for bug#42208 | Ann W. Harrison | 18 Feb |
| • Re: Patch for bug#42208 | MARK CALLAGHAN | 17 Feb |
| • Re: Patch for bug#42208 | Jim Starkey | 16 Feb |
