Re: postgres8.3beta encodding problem?

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

In response to

Browse pgsql-general by date

  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?