> Celia McInnis <[EMAIL PROTECTED]> wrote:
949 base 10 = 1110110101 base two.
select 949::bit(10) gives 1110110101 (as expected).
Bruno Wolff III wrote:
Why is that expected? Based on your reasoning for the last case I would
expect '00', since the first 10 bits of that integer are 0.
Good
On Thu, May 12, 2005 at 10:40:34 -0500,
Celia McInnis <[EMAIL PROTECTED]> 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
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 = 11
"Celia McInnis" <[EMAIL PROTECTED]> 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 sele
Bruce Momjian writes:
> ... Though this is slightly inconsistent in how it works with a
> bit string, it does seem the most useful approach.
Also, this is a behavior that we changed in 8.0 in response to previous
complaints. Before changing it again, I'd want to see a pretty detailed
analysis of
Celia McInnis wrote:
>
> The following bug has been logged online:
>
> Bug reference: 1578
> Logged by: Celia McInnis
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.0.1
> Operating system: Linux
> Description:::bit(n) behaves "differently" if applied to bi
The following bug has been logged online:
Bug reference: 1578
Logged by: Celia McInnis
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.1
Operating system: Linux
Description:::bit(n) behaves "differently" if applied to bit strings
than integers.
Details:
It'
