>>> On Tue, Nov 20, 2007 at 3:47 PM, in message
<24B6EF3D-B0BC-44EB-ADD1-257AE9A51FD4(at)otii(dot)com>, Cade Cairns <cadec(at)otii(dot)com>
> On 20-Nov-07, at 2:42 PM, Heikki Linnakangas wrote:
>> "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)
i) If the length of TV is less than the length of SVC, then a
completion condition is raised: warning-string data, right
ii) If the length of TV is greater than the length of SVC, then
a completion condition is raised: warning-implicit zero-bit
In response to
pgsql-bugs by date
|Next:||From: Thomas Haegi||Date: 2007-11-21 02:22:58|
|Subject: BUG #3766: tsearch2 index creation error|
|Previous:||From: Cade Cairns||Date: 2007-11-20 21:47:46|
|Subject: Re: BUG #3765: strange results for bit string hex notation cast to bit|