Re: postgres8.3beta encodding problem? - Mailing list pgsql-general

From Martijn van Oosterhout
Subject Re: postgres8.3beta encodding problem?
Date
Msg-id 20071218155403.GF13268@svana.org
Whole thread Raw
In response to Re: postgres8.3beta encodding problem?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: postgres8.3beta encodding problem?
Re: postgres8.3beta encodding problem?
List pgsql-general
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)))

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.

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.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Those who make peaceful revolution impossible will make violent revolution inevitable.
>  -- John F Kennedy

Attachment

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: postgres8.3beta encodding problem?
Next
From: "Weber, Geoffrey M."
Date:
Subject: Problem with index not being chosen inside PL/PgSQL function...