Обсуждение: BUG #3765: strange results for bit string hex notation cast to bit

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)

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

Can anyone explain why this is the case?

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

> 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
>

>>> On Tue, Nov 20, 2007 at  3:47 PM, in message
<24B6EF3D-B0BC-44EB-ADD1-257AE9A51FD4@otii.com>, Cade Cairns <cadec@otii.co=
m>
wrote:=20
> 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=20=20
>> will be truncated or zero-padded on the right to be exactly n bits,=20=
=20
>> without raising an error. Similarly, if one explicitly casts a bit-=20
>> string value to bit varying(n), it will be truncated on the right if=20=
=20
>> it is more than n bits."
>
> Can anyone explain why this is the case?
=20
That's the correct result, as I read the CAST specification in the
ANSI standard; although I think this should generate a warning.
=20
            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.
=20
-Kevin
=20