BUG #3765: strange results for bit string hex notation cast to bit

Started by Cade Cairnsover 18 years ago4 messagesbugs
Jump to latest
#1Cade Cairns
cadec@otii.com

The following bug has been logged online:

Bug reference: 3765
Logged by: Cade Cairns
Email address: cadec@otii.com
PostgreSQL version: 8.1.10
Operating system: Mac OS X 10.5.1
Description: strange results for bit string hex notation cast to bit
Details:

When casting a bit string constant using hexadecimal notation to a longer
bit string, the result is padded with 0's on the right. This will result in
inconsistent/useless results:

test=# select x'ff'::integer;
int4
------
255
(1 row)

test=# select x'ff'::bit(16)::integer;
int4
-------
65280
(1 row)

#2Heikki Linnakangas
heikki.linnakangas@enterprisedb.com
In reply to: Cade Cairns (#1)
Re: BUG #3765: strange results for bit string hex notation cast to bit

Cade Cairns wrote:

When casting a bit string constant using hexadecimal notation to a longer
bit string, the result is padded with 0's on the right. This will result in
inconsistent/useless results:

test=# select x'ff'::integer;
int4
------
255
(1 row)

test=# select x'ff'::bit(16)::integer;
int4
-------
65280
(1 row)

It works like it should according to the manual:

http://www.postgresql.org/docs/8.1/interactive/datatype-bit.html

"Note: If one explicitly casts a bit-string value to bit(n), it will be
truncated or zero-padded on the right to be exactly n bits, without
raising an error. Similarly, if one explicitly casts a bit-string value
to bit varying(n), it will be truncated on the right if it is more than
n bits."

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

#3Cade Cairns
cadec@otii.com
In reply to: Heikki Linnakangas (#2)
Re: BUG #3765: strange results for bit string hex notation cast to bit

Can anyone explain why this is the case?

On 20-Nov-07, at 2:42 PM, Heikki Linnakangas wrote:

Show quoted text

Cade Cairns wrote:

When casting a bit string constant using hexadecimal notation to a
longer
bit string, the result is padded with 0's on the right. This will
result in
inconsistent/useless results:
test=# select x'ff'::integer;
int4 ------
255
(1 row)
test=# select x'ff'::bit(16)::integer;
int4 -------
65280
(1 row)

It works like it should according to the manual:

http://www.postgresql.org/docs/8.1/interactive/datatype-bit.html

"Note: If one explicitly casts a bit-string value to bit(n), it
will be truncated or zero-padded on the right to be exactly n bits,
without raising an error. Similarly, if one explicitly casts a bit-
string value to bit varying(n), it will be truncated on the right if
it is more than n bits."

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

#4Kevin Grittner
Kevin.Grittner@wicourts.gov
In reply to: Cade Cairns (#3)
Re: BUG #3765: strange results for bit string hex notation cast to bit

On Tue, Nov 20, 2007 at 3:47 PM, in message

<24B6EF3D-B0BC-44EB-ADD1-257AE9A51FD4@otii.com>, Cade Cairns <cadec@otii.com>
wrote:

On 20-Nov-07, at 2:42 PM, Heikki Linnakangas wrote:

http://www.postgresql.org/docs/8.1/interactive/datatype-bit.html

"Note: If one explicitly casts a bit-string value to bit(n), it
will be truncated or zero-padded on the right to be exactly n bits,
without raising an error. Similarly, if one explicitly casts a bit-
string value to bit varying(n), it will be truncated on the right if
it is more than n bits."

Can anyone explain why this is the case?

That's the correct result, as I read the CAST specification in the
ANSI standard; although I think this should generate a warning.

d) If SD is fixed-length bit string or variable-length bit
string, then let LSV be the value of BIT_LENGTH(SV) and let
B be the BIT_LENGTH of the character with the smallest BIT_
LENGTH in the form-of-use of TD. Let PAD be the value of the
remainder of the division LSV/B. Let NC be a character whose
bits all have the value 0.

If PAD is not 0, then append (B - PAD) 0-valued bits to
the least significant end of SV; a completion condition is
raised: warning-implicit zero-bit padding.

Let SVC be the possibly padded value of SV expressed as a
character string without regard to valid character encodings
and let LTDS be a character string of LTD characters of value
NC characters in the form-of-use of TD.

TV is the result of

SUBSTRING (SVC | LTDS FROM 1 FOR LTD)

Case:

i) If the length of TV is less than the length of SVC, then a
completion condition is raised: warning-string data, right
truncation.

ii) If the length of TV is greater than the length of SVC, then
a completion condition is raised: warning-implicit zero-bit
padding.

-Kevin