Cleanup of my_hash_sort patch
strings/ctype-uca.c: HASH needs to be done in opposite order to preserve partitioned tables
This commit is contained in:
parent
6a576f1a58
commit
9276e0e911
@ -20902,12 +20902,21 @@ static void my_hash_sort_uca(CHARSET_INFO *cs,
|
|||||||
/* Add back that has for the space characters */
|
/* Add back that has for the space characters */
|
||||||
do
|
do
|
||||||
{
|
{
|
||||||
MY_HASH_ADD_16(m1, m2, space_weight);
|
/*
|
||||||
|
We can't use MY_HASH_ADD_16() here as we, because of a misstake
|
||||||
|
in the original code, where we added the 16 byte variable the
|
||||||
|
opposite way. Changing this would cause old partitioned tables
|
||||||
|
to fail.
|
||||||
|
*/
|
||||||
|
MY_HASH_ADD(m1, m2, space_weight >> 8);
|
||||||
|
MY_HASH_ADD(m1, m2, space_weight & 0xFF);
|
||||||
}
|
}
|
||||||
while (--count != 0);
|
while (--count != 0);
|
||||||
|
|
||||||
}
|
}
|
||||||
MY_HASH_ADD_16(m1, m2, s_res);
|
/* See comment above why we can't use MY_HASH_ADD_16() */
|
||||||
|
MY_HASH_ADD(m1, m2, s_res >> 8);
|
||||||
|
MY_HASH_ADD(m1, m2, s_res & 0xFF);
|
||||||
}
|
}
|
||||||
end:
|
end:
|
||||||
*nr1= m1;
|
*nr1= m1;
|
||||||
|
@ -109,11 +109,4 @@ static inline const uchar *skip_trailing_space(const uchar *ptr,size_t len)
|
|||||||
#define MY_HASH_ADD_16(A, B, value) \
|
#define MY_HASH_ADD_16(A, B, value) \
|
||||||
do { MY_HASH_ADD(A, B, ((value) & 0xFF)) ; MY_HASH_ADD(A, B, ((value >>8 ))); } while(0)
|
do { MY_HASH_ADD(A, B, ((value) & 0xFF)) ; MY_HASH_ADD(A, B, ((value >>8 ))); } while(0)
|
||||||
|
|
||||||
/*
|
|
||||||
This one is needed to ensure we get the exact same hash as MariaDB 5.1
|
|
||||||
This is needed to ensure that old partitioned tables still work as before.
|
|
||||||
*/
|
|
||||||
#define MY_HASH_ADD_16_INV(A, B, value) \
|
|
||||||
do { MY_HASH_ADD(A, B, ((value >> 8))) ; MY_HASH_ADD(A, B, ((value & 0xFF ))); } while(0)
|
|
||||||
|
|
||||||
#endif
|
#endif
|
||||||
|
Loading…
x
Reference in New Issue
Block a user