## Re: BUG #1578: ::bit(n) behaves "differently" if applied to bit

From: Celia McInnis Bruno Wolff III Tom Lane ,Bruce Momjian , pgsql-bugs(at)postgresql(dot)org Re: BUG #1578: ::bit(n) behaves "differently" if applied to bit 2005-05-14 05:33:19 42858D9F.2000409@drmath.ca (view raw or whole thread) 2005-04-04 19:28:28 from "Celia McInnis"  2005-05-11 03:25:33 from Bruce Momjian   2005-05-11 05:36:51 from Tom Lane    2005-05-12 15:40:34 from "Celia McInnis"     2005-05-12 16:01:08 from Tom Lane     2005-05-13 16:33:27 from Bruno Wolff III      2005-05-14 05:33:19 from Celia McInnis pgsql-bugs
``` >   Celia McInnis <celia(at)drmath(dot)ca> wrote:
>>949 base 10 = 1110110101 base two.
>>
>>select 949::bit(10) gives 1110110101 (as expected).

Bruno Wolff III wrote:
> Why is that expected? Based on your reasoning for the last case I would
> expect '0000000000', since the first 10 bits of that integer are 0.

Good - you see the inconsistency which I was pointing out - that casting
to bit(n)'s is done "differently" for integers than it is for bit(m)'s!

In terms of "as expected", I meant "as expected by a mathematician" -
ie., that I'd expect that casting an integer (in the mathematical sense
rather than in some limited-storage redefinition made by computer
scientists) to a bit string would give the base two representation of
the integer provided the bit string is long enough (as it was in my
example).

It's actually too bad that the SQL standard took the MSB route rather
than the LSB route for bit(n)->bit(m) casting, since it kind of requires
the inconsistency given above in dealing with integers in order to be
functional. Tom Lane explained this very well. Anyway, I'm happy that
949::bit(10) gives 1110110101 which is the base 2 representation of 949
(and I'm sure that nobody would be impressed if they had to start
worrying about the effect of changing to machines with different
(computer-science) integer sizes), so, unless somebody changes the SQL
standard for bit(n), I appreciate that the postgresql developers have
made a sensible choice concerning casting from integers to bit(n).

Thanks very much for helping me to understand,
Celia McInnis
(who'll just have to "get over" her discomfort for the below :-) )

>>select 949::bit(10)::bit(3) gives 111 (the 3 most significant bits)
>>select 949::bit(3) gives 101 (the 3 least significant bits).
>>
>>As a mathematician, I'd certainly at least want the last two selects to give
>>the same results!

```

### pgsql-bugs by date

 Next: From: Bruce Momjian Date: 2005-05-14 16:40:15 Subject: Re: Fwd: Bug#308535: postgresql-client: [psql] manual page does Previous: From: Mark Dilger Date: 2005-05-14 01:07:29 Subject: BUG #1671: Long interval string representation rejected