Re: BUG #1578: ::bit(n) behaves "differently" if applied to bit - Mailing list pgsql-bugs

From Bruno Wolff III
Subject Re: BUG #1578: ::bit(n) behaves "differently" if applied to bit
Date
Msg-id 20050513163327.GA8214@wolff.to
Whole thread Raw
In response to Re: BUG #1578: ::bit(n) behaves "differently" if applied to bit  ("Celia McInnis" <celia@drmath.ca>)
Responses Re: BUG #1578: ::bit(n) behaves "differently" if applied to bit  (Celia McInnis <celia@drmath.ca>)
List pgsql-bugs
On Thu, May 12, 2005 at 10:40:34 -0500,
  Celia McInnis <celia@drmath.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!

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fwd: Bug#308513: postgresql-client: [manual] createuser(1) Add example '...WITH PASSWORD'
Next
From: Euler Taveira de Oliveira
Date:
Subject: Re: BUG #1662: Table constrains are not properly inherited.