From: | Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz> |
---|---|
To: | John R Pierce <pierce(at)hogranch(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #8191: Wrong bit conversion |
Date: | 2013-06-01 02:38:45 |
Message-ID: | 51A95EB5.9000104@archidevsys.co.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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
From | Date | Subject | |
---|---|---|---|
Next Message | John R Pierce | 2013-06-01 04:26:10 | Re: BUG #8191: Wrong bit conversion |
Previous Message | Gavin Flower | 2013-06-01 01:01:05 | Re: BUG #8191: Wrong bit conversion |