From: | Bruno Wolff III <bruno(at)wolff(dot)to> |
---|---|
To: | Celia McInnis <celia(at)drmath(dot)ca> |
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-13 16:33:27 |
Message-ID: | 20050513163327.GA8214@wolff.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Thu, May 12, 2005 at 10:40:34 -0500,
Celia McInnis <celia(at)drmath(dot)ca> wrote:
> Thanks very much Bruce and Tom for your responses and explanations. The
> current mode of operation is mathematically disturbing so I'm hoping that you
> can figure out some sort of a fix! Perhaps this example is a little more
> convincing than my last one at showing the bug/feature:
>
> 949 base 10 = 1110110101 base two.
>
> select 949::bit(10) gives 1110110101 (as expected).
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.
> 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!
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-05-13 16:34:02 | Re: Fwd: Bug#308513: postgresql-client: [manual] createuser(1) Add example '...WITH PASSWORD' |
Previous Message | David Walker | 2005-05-13 16:09:00 | Re: initdb fails on ultra2. followup |