> 7 апр. 2021 г., в 13:23, Heikki Linnakangas <hlinn...@iki.fi> написал(а):
>
> Committed with small fixes.
Thanks!
> 7 апр. 2021 г., в 14:56, Heikki Linnakangas <hlinn...@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 without the '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 it operates 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.
