List:Falcon Storage Engine« Previous MessageNext Message »
From:Ann W. Harrison Date:February 17 2009 11:31pm
Subject:Re: Patch for bug#42208
View as plain text  
Kevin,


> According to the blog link forwarded by Mark, Oracle customers don not 
> like that zero length strings (which are equal to each other) are 
> automatically converted to NULLs.  Both suggestions take care of that in 
> Falcon.  So this is the most important thing; make a zero length string 
> equal to 0x00 length 1.

Oracle's bad behavior is to treat real varchar strings of length zero
as nulls, thus confusing the case of an unknown middle name and no
middle name at all.  Varbinary is a MySQL invention, so I guess MySQL
gets to set the rules.  (Firebird took the simplifying assumption
that its equivalent, the character set OCTETS, uses 0x00 like a space
in other character sets, so 0x00, 0x0000, etc. are equal by definition.)
I agree that being part of MySQL, we should behave like MySQL.

> 
> The question is whether to keep adding 0x00 to other lengths of binary 
> zero strings.  Jim says it does not matter to anyone but QA that 0x00 
> and 0x0000 sort separately.  And Vlad points out that even if we did 
> this for single field keys, it would not sort them differently for 
> multisegment key since we always pad them to a RUN length.  I think that 
> if it does not cause any extra difficulties or complexity in the code, 
> why not keep QA happy for single segment keys.

Philip is never going to be happy.  And now that we've told him the
dirty secret, he'll set up a limit test that turns on the value of
the first segment of a multi-segment key being exactly 0x00.
> 
> And I still am unclear why this little change in index order should 
> cause us to change the ODS format while still in the alpha stage.  What 
> is the downside of a new engine that starts converting zero length 
> strings into 0x00?  New entries will be added to the index after the 
> NULLS.  Older zero length strings would be mixed up with the NULLS and 
> may not be found for direct searched until the index is rebuilt.  We can 
> document that as a bug fix in the index, which it is. Nobodies critical 
> data is depending on us finding all zero length strings.

The problem is no in differentiating between 0x00, 0x00, and null in
varbinary.  The problem is that nulls in numeric keys have been stored
as zero and now they have to be stored as the lowest possible value.
That means that the new index code won't be able to find nulls in
old indexes at all.  That's a bigger problem.  But is it a big
enough problem to increase the minor ODS and the version of indexes
and maintain code that can generate a key that works with old indexes?
I don't think so.

Cheers,

Ann
Thread
Patch for bug#42208Lars-Erik Bjørk16 Feb
  • RE: Patch for bug#42208Vladislav Vaintroub16 Feb
    • RE: Patch for bug#42208Vladislav Vaintroub16 Feb
      • Re: Patch for bug#42208Jim Starkey16 Feb
        • RE: Patch for bug#42208Vladislav Vaintroub16 Feb
    • Re: Patch for bug#42208Jim Starkey16 Feb
      • RE: Patch for bug#42208Vladislav Vaintroub16 Feb
      • Re: Patch for bug#42208Lars-Erik Bjørk17 Feb
        • Re: Patch for bug#42208Kevin Lewis17 Feb
          • Re: Patch for bug#42208Ann W. Harrison18 Feb
            • Re: Patch for bug#42208Ann W. Harrison18 Feb
              • Re: Patch for bug#42208Ann W. Harrison18 Feb
                • Re: Patch for bug#42208Kevin Lewis18 Feb
                  • Re: Patch for bug#42208Ann W. Harrison18 Feb
                    • Re: Patch for bug#42208Kevin Lewis18 Feb
          • RE: Patch for bug#42208Vladislav Vaintroub18 Feb
            • RE: Patch for bug#42208Vladislav Vaintroub18 Feb
              • Re: Patch for bug#42208Kevin Lewis18 Feb
                • RE: Patch for bug#42208Vladislav Vaintroub18 Feb
                  • RE: Patch for bug#42208Vladislav Vaintroub18 Feb
              • Re: Patch for bug#42208Jim Starkey18 Feb
                • RE: Patch for bug#42208Vladislav Vaintroub18 Feb
                  • Re: Patch for bug#42208Jim Starkey18 Feb
                    • RE: Patch for bug#42208Vladislav Vaintroub18 Feb
                      • RE: Patch for bug#42208Vladislav Vaintroub18 Feb
            • Re: Patch for bug#42208Ann W. Harrison18 Feb
              • RE: Patch for bug#42208Vladislav Vaintroub18 Feb
                • Re: Patch for bug#42208Jim Starkey18 Feb
                  • Re: Patch for bug#42208Ann W. Harrison18 Feb
                    • Re: Patch for bug#42208Ann W. Harrison18 Feb
                • Re: Patch for bug#42208Ann W. Harrison18 Feb
                  • RE: Patch for bug#42208Vladislav Vaintroub18 Feb
                    • Re: Patch for bug#42208Ann W. Harrison18 Feb
                    • Re: Patch for bug#42208Kevin Lewis18 Feb
                      • Re: Patch for bug#42208Ann W. Harrison18 Feb
      • Re: Patch for bug#42208MARK CALLAGHAN17 Feb
  • Re: Patch for bug#42208Jim Starkey16 Feb