Thread: BUG #8191: Wrong bit conversion

The following bug has been logged on the website:

Bug reference:      8191
Logged by:          Gerald Luger
Email address:      gerald@hexboss.com
PostgreSQL version: 9.2.1
Operating system:   Windows 8
Description:        =


SELECT b'1'::bit(64), x'1'::bit(64), 1::bit(64)

RESULT:
"1000000000000000000000000000000000000000000000000000000000000000",
"0001000000000000000000000000000000000000000000000000000000000000",
"0000000000000000000000000000000000000000000000000000000000000001"

gerald@hexboss.com writes:
> SELECT b'1'::bit(64), x'1'::bit(64), 1::bit(64)

> RESULT:
> "1000000000000000000000000000000000000000000000000000000000000000",
> "0001000000000000000000000000000000000000000000000000000000000000",
> "0000000000000000000000000000000000000000000000000000000000000001"

I believe those are all operating as intended.

            regards, tom lane

Shouldn't I expect all results to be 000...0001?

Otherwise it would be
1 !=3D 1?


-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]=20
Sent: Friday, May 31, 2013 5:34 PM
To: Gerald Luger
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #8191: Wrong bit conversion

gerald@hexboss.com writes:
> SELECT b'1'::bit(64), x'1'::bit(64), 1::bit(64)

> RESULT:
> "1000000000000000000000000000000000000000000000000000000000000000",
> "0001000000000000000000000000000000000000000000000000000000000000",
> "0000000000000000000000000000000000000000000000000000000000000001"

I believe those are all operating as intended.

            regards, tom lane

On 5/31/2013 4:29 PM, Gerald Luger wrote:
> Shouldn't I expect all results to be 000...0001?
>
> Otherwise it would be
> 1 != 1?

SQL's BIT type is big endian, a hangover from its IBM mainframe heritage.





--
john r pierce                                      37N 122W
somewhere on the middle of the left coast

On 01/06/13 12:29, John R Pierce wrote:
> On 5/31/2013 4:29 PM, Gerald Luger wrote:
>> Shouldn't I expect all results to be 000...0001?
>>
>> Otherwise it would be
>> 1 != 1?
>
> SQL's BIT type is big endian, a hangover from its IBM mainframe heritage.
>
>
>
>
>
I don't think it has anything to do with byte sex (I know of 3 ways to
store integers in memory, and I suspect there are more !).

Don't confuse how things are displayed with how they are stored in memory.

Just that
1 = two to the power of zero
so it seems logical to start numbering the bits to represent the powers
of 2.


Cheers,
Gavin

On 01/06/13 13:01, Gavin Flower wrote:
> On 01/06/13 12:29, John R Pierce wrote:
>> On 5/31/2013 4:29 PM, Gerald Luger wrote:
>>> Shouldn't I expect all results to be 000...0001?
>>>
>>> Otherwise it would be
>>> 1 != 1?
>>
>> SQL's BIT type is big endian, a hangover from its IBM mainframe
>> heritage.
>>
>>
>>
>>
>>
> I don't think it has anything to do with byte sex (I know of 3 ways to
> store integers in memory, and I suspect there are more !).
>
> Don't confuse how things are displayed with how they are stored in memory.
>
> Just that
> 1 = two to the power of zero
> so it seems logical to start numbering the bits to represent the
> powers of 2.
>
>
> Cheers,
> Gavin
Hmm...

On second thoughts, it is strange that the first 2 examples affect bits
on the left hand side!

So now I think, that all 3 examples should logically be:

RESULT:
"0000000000000000000000000000000000000000000000000000000000000001",

BUT, But, But...

It appears for varchar padding is done on the right hand side, so maybe that is why the first 2examples are as they are
(suggestive,not proof!). 


Cheers,
Gavin

On 5/31/2013 6:01 PM, Gavin Flower wrote:
>> SQL's BIT type is big endian, a hangover from its IBM mainframe
>> heritage.
>>
>>
>>
>>
>>
> I don't think it has anything to do with byte sex (I know of 3 ways to
> store integers in memory, and I suspect there are more !).

I was thinking of bit sex, not byte.

IBM numbers bits such that bit 0 is the most significant bit of a word.


--
john r pierce                                      37N 122W
somewhere on the middle of the left coast

Gerald Luger <GeraldLuger@hexboss.com> writes:
> Shouldn't I expect all results to be 000...0001?

Well, no.

The SQL spec is pretty clear about the interpretation of this:
    b'1'::bit(64)
You're taking a bit string of length 1 and casting it to bit string
of length 64.  That's done by appending zeroes on the right, per spec.

The x'1' notation isn't in SQL99 AFAICS, but we consider that x'1'
means the same as b'0001', and then the conversion from bit(4) to
bit(64) is done by padding zeroes on the right.

Your last case,
    1::bit(64)
represents casting an integer to bit(64).  This operation isn't in the
SQL spec either, unless I missed something.  We treat this as conversion
of the integer's twos-complement representation to a bit string,
presuming big-endian representation of the integer.

Now you can quibble with various of the details above, but in the end
they are all arbitrary decisions.  We've made them that way, and it
would take a pretty impressive argument to persuade us to break existing
applications by changing them.

            regards, tom lane