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

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

Bill Moran  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

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

"Thomas Swan"  writes:
> To convert low bits ot high bits you pad 0 bits on the left.   To convert
> from high to low you strip bits off the left hand side.  This allows
> reasonable behavior.

Unfortunately, the SQL spec is perfectly clear that you pad or strip
zero bits on the *right* of the bit string.  We cannot change that.

It might have been better if we had defined int<->bit casts to treat
the first bit of the bit string as the LSB of the integer.  But we
didn't, and it's probably too big a change to consider.

			regards, tom lane

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

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