From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, marcelo Cortez <jmdc_marcelo(at)yahoo(dot)com(dot)ar>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: postgres8.3beta encodding problem? |
Date: | 2007-12-18 16:00:08 |
Message-ID: | 29674.1197993608@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> 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.
Well, the advertised purpose of the chr() changes was to prevent
generation of invalid multibyte sequences, not to cut off
potentially-useful functionality. So I don't think it should be
preventing people from generating non-ASCII single-byte characters.
The test is clearly backwards, because in an MB encoding it will in fact
let you generate invalid encoding ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Weber, Geoffrey M. | 2007-12-18 16:00:29 | Problem with index not being chosen inside PL/PgSQL function... |
Previous Message | Martijn van Oosterhout | 2007-12-18 15:54:03 | Re: postgres8.3beta encodding problem? |