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

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!

In response to

Responses

Browse pgsql-bugs by date

  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