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

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Celia McInnis" <celia(at)drmath(dot)ca>
Cc: 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-12 16:01:08
Message-ID: 1991.1115913668@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
"Celia McInnis" <celia(at)drmath(dot)ca> writes:
> select 949::bit(10) gives 1110110101 (as expected).
> 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!

Unfortunately, the behavior of casting between bit(m) and bit(n) is not
open to negotiation --- it's given by the SQL standard.

I think the only way to make this stuff truly mathematically consistent
would be to go over to a "little endian" approach in which casting from
integer to bit puts the LSB of the integer into the first, not the last,
bit of the bit string.  But that is probably too big a compatibility
hit to consider ... and I for one would find it less useful not more.

			regards, tom lane

In response to

pgsql-bugs by date

Next:From: Andrew FabbroDate: 2005-05-12 16:20:14
Subject: BUG #1665: postgresql-8.0.3.zip corrupt
Previous:From: Celia McInnisDate: 2005-05-12 15:40:34
Subject: Re: BUG #1578: ::bit(n) behaves "differently" if applied to bit

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