> 7 апр. 2021 г., в 13:23, Heikki Linnakangas <hlinnaka@iki.fi> написал(а):
>
> Committed with small fixes.
Thanks!
> 7 апр. 2021 г., в 14:56, Heikki Linnakangas <hlinnaka@iki.fi> написал(а):
>
> Ok, I think I understand that now. In btree_gist, the *_cmp() function operates on non-leaf values, and *_lt(),
*_gt()et al operate on leaf values. For all other datatypes, the leaf and non-leaf representation is the same, but for
bit/varbit,the non-leaf representation is different. The leaf representation is VarBit, and non-leaf is just the bits
withoutthe 'bit_len' field. That's why it is indeed correct for gbt_bitcmp() to just use byteacmp(), whereas
gbt_bitlt()et al compares the 'bit_len' field separately. That's subtle, and 100% uncommented.
>
> What that means for this patch is that gbt_bit_sort_build_cmp() should *not* call byteacmp(), but bitcmp(). Because
itoperates on the original datatype stored in the table.
+1
Thanks for investigating this.
If I understand things right, adding test values with different lengths of bit sequences would not uncover the problem
anyway?
Best regards, Andrey Borodin.
