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!
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
