Pavel Raiskup <prais...@redhat.com> writes: > On Monday, July 9, 2018 7:41:59 PM CEST Tom Lane wrote: >> Hi Pavel! For patches that purport to resolve bugs, we usually like to >> add a regression test case that demonstrates the bug in unpatched code. >> Can you provide a small test case that does so? (The BZ you pointed to >> doesn't seem to address this...)
> Turns out the problem is only related to bit/bit varying type (so the > patch comments need to be reworded properly, at least) since those are the > only types which have implemented the f_l2n() callback. What I'm failing to wrap my head around is why this code exists at all. AFAICS, gbt_bit_xfrm just forces the bitstring to be zero-padded out to an INTALIGN boundary, which it wouldn't necessarily be otherwise. But why bother? That should have no effect on the behavior of bit_cmp(). So I'm speculating that the reason nobody has noticed a problem is that there is no problem because this code is useless and could be ripped out. It would be easier to figure this out if the btree_gist code weren't so desperately undocumented. Teodor, do you remember why it's like this? regards, tom lane