Skip site navigation (1) Skip section navigation (2)

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

From: Celia McInnis <celia(at)drmath(dot)ca>
To: Bruno Wolff III <bruno(at)wolff(dot)to>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #1578: ::bit(n) behaves "differently" if applied to bit
Date: 2005-05-14 05:33:19
Message-ID: 42858D9F.2000409@drmath.ca (view raw or flat)
Thread:
Lists: 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!



In response to

pgsql-bugs by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group