Re: [PATCH] btree_gist: fix union implementation for variable length columns
От | Pavel Raiskup |
---|---|
Тема | Re: [PATCH] btree_gist: fix union implementation for variable length columns |
Дата | |
Msg-id | 4076084.lpus4j4ZWx@nb.usersys.redhat.com обсуждение исходный текст |
Ответ на | Re: [PATCH] btree_gist: fix union implementation for variable length columns (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Wednesday, July 11, 2018 7:26:40 PM CEST Tom Lane wrote: > Pavel Raiskup <praiskup@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(). The gbt_bit_xfrm() method actually also skips the varbit header (number of bits, stored in VarBit.bit_len), the magic is done by VARBITS macro. If the header is dropped, it's OK to just use existing byteacmp() for bit array comparison. Pavel
В списке pgsql-hackers по дате отправления: