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

> 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!