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

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: (view raw, whole thread or download thread mbox)
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


pgsql-bugs by date

Next:From: Tom LaneDate: 2005-05-13 16:34:02
Subject: Re: Fwd: Bug#308513: postgresql-client: [manual] createuser(1) Add example '...WITH PASSWORD'
Previous:From: David WalkerDate: 2005-05-13 16:09:00
Subject: Re: initdb fails on ultra2. followup

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