Обсуждение: 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