Re: BUG #16403: set_bit function does not have expected effect

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Francisco Olarte <folarte(at)peoplecall(dot)com>
Cc: amovitz(at)bncpu(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #16403: set_bit function does not have expected effect
Date: 2020-04-30 13:57:46
Message-ID: 20591.1588255066@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Francisco Olarte <folarte(at)peoplecall(dot)com> writes:
> On Thu, Apr 30, 2020 at 9:47 AM PG Bug reporting form
> <noreply(at)postgresql(dot)org> wrote:
>> set_bit function changes the right-most bit of the byte, but with
>> little-endian byte order. This is confusing to any use case where setting a
>> bit in a BYTEA in a specific position. To iterate through the bits within
>> the BYTEA, one must have nested loops which set bits within byte boundaries.

> I think this is a display expectations issue, when using addresses it
> seems it is changing the least significant bit in the first byte and
> the second byte ( in C-speak it is setting bit n%8 byte n/8 ),

Yeah, the documentation is quite clear about this:

Functions get_byte and set_byte number the first byte of a binary
string as byte 0. Functions get_bit and set_bit number bits from the
right within each byte; for example bit 0 is the least significant bit
of the first byte, and bit 15 is the most significant bit of the
second byte.

so we're not likely to change it.

You might consider using type "bit" instead of bytea, since the bit
display order is more closely tied to how set_bit() numbers the bits.

Another option is to write your own functions that number the bits
however you want.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2020-04-30 14:08:44 Re: BUG #16404: PostgreSQL 12.2: Database restore does not accept the EEST time zone.
Previous Message Tom Lane 2020-04-30 13:47:02 Re: report bug