Martijn van Oosterhout wrote:
> On Tue, Dec 18, 2007 at 10:35:39AM -0500, Tom Lane wrote:
>
>> Martijn van Oosterhout <kleptog@svana.org> writes:
>>
>>> Ok, but that doesn't apply in this case, his database appears to be
>>> LATIN1 and this character is valid for that encoding...
>>>
>> You know what, I think the test in the code is backwards.
>>
>> is_mb = pg_encoding_max_length(encoding) > 1;
>>
>> if ((is_mb && (cvalue > 255)) || (!is_mb && (cvalue > 127)))
>>
Yes.
>
> It does seem to be a bit wierd. For single character encodings anything
> up to 255 is OK, well, sort of. It depends on what you want chr() to do
> (oh no, not this discussion again). If you subscribe to the idea that
> it should use unicode code points then the test is completely bogus,
> since whether or not the character is valid has nothing to with whether
> the encoding is multibyte or not.
>
We are certainly not going to revisit that discussion at this stage. It
was thrashed out months ago.
> If you want the output of th chr() to (logically) depend on the encoding
> then the test makes more sense, but ten it's inverted. Single-byte
> encodings are by definition defined to 255 characters. And multibyte
> encodings (other than UTF-8 I suppose) can only see the ASCII subset.
>
Right. There is a simple thinko on my part in the line of code Tom
pointed to, which needs to be fixed.
cheers
andrew