[BUGS] BUG #8191: Wrong bit conversion
The following bug has been logged on the website: Bug reference: 8191 Logged by: Gerald Luger Email address: ger...@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: 1000, 0001, 0001 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8191: Wrong bit conversion
ger...@hexboss.com writes: SELECT b'1'::bit(64), x'1'::bit(64), 1::bit(64) RESULT: 1000, 0001, 0001 I believe those are all operating as intended. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8191: Wrong bit conversion
Shouldn't I expect all results to be 000...0001? Otherwise it would be 1 != 1? -Original Message- From: Tom Lane [mailto:t...@sss.pgh.pa.us] Sent: Friday, May 31, 2013 5:34 PM To: Gerald Luger Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] BUG #8191: Wrong bit conversion ger...@hexboss.com writes: SELECT b'1'::bit(64), x'1'::bit(64), 1::bit(64) RESULT: 1000, 0001, 0001 I believe those are all operating as intended. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8191: Wrong bit conversion
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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8191: Wrong bit conversion
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
Re: [BUGS] BUG #8191: Wrong bit conversion
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: 0001, 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
Re: [BUGS] BUG #8191: Wrong bit conversion
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
Re: [BUGS] BUG #8191: Wrong bit conversion
Gerald Luger geraldlu...@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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
