Re: Shouldn't B'1' = 1::bit be true?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bill Moran <wmoran(at)potentialtech(dot)com>
Cc: pgsql-general(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Shouldn't B'1' = 1::bit be true?
Date: 2004-03-09 23:43:58
Message-ID: 29881.1078875838@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Bill Moran <wmoran(at)potentialtech(dot)com> writes:
> Am I missing something here?

Hmm. It seems like int-to-bit casting ought to be aware of the
bit-width one is casting to, and take that number of bits from
the right end of the integer. This would make it be the inverse
of the other direction. Right now it's only an inverse when you
cast to and from bit(32). For shorter bitfield widths, we're
effectively inserting at the right end of the integer, but removing
bits from the left, which is not consistent.

regression=# select B'11000'::bit(5)::int;
int4
------
24
(1 row)

regression=# select 24::int::bit(32);
bit
----------------------------------
00000000000000000000000000011000
(1 row)

regression=# select 24::int::bit(32)::bit(5);
bit
-------
00000
(1 row)

regression=# select 24::int::bit(5);
bit
-------
00000
(1 row)

If we made int-to-bit-N take the rightmost N bits, then the last two
cases would yield different results, but that doesn't seem unreasonable
to me. Or at least it's less unreasonable than bit(5)-to-int not being
the inverse of int-to-bit(5).

Comments?

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bill Moran 2004-03-10 00:31:06 Re: Shouldn't B'1' = 1::bit be true?
Previous Message Stephan Szabo 2004-03-09 23:34:36 Re: Shouldn't B'1' = 1::bit be true?

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-03-09 23:50:31 Re: Stuff that doesn't work yet in IPv6 patch
Previous Message Stephan Szabo 2004-03-09 23:34:36 Re: Shouldn't B'1' = 1::bit be true?