Re: Bug in UTF8-Validation Code?

Martijn van Oosterhout <kleptog@svana.org>

From: Martijn van Oosterhout <kleptog@svana.org>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Jeff Davis <pgsql@j-davis.com>, Michael Fuhr <mike@fuhr.org>, Mario Weilguni <mweilguni@sime.com>, "Joshua D. Drake" <jd@commandprompt.com>, Albe Laurenz <all@adv.magwien.gv.at>, pgsql-hackers@postgresql.org
Date: 2007-03-18T11:36:22Z
Lists: pgsql-hackers
On Sat, Mar 17, 2007 at 11:46:01AM -0400, Andrew Dunstan wrote:
> How can we fix this? Frankly, the statement in the docs warning about 
> making sure that escaped sequences are valid in the server encoding is a 
> cop-out. We don't accept invalid data elsewhere, and this should be no 
> different IMNSHO. I don't see why this should be any different from, 
> say, date or numeric data. For years people have sneered at MySQL 
> because it accepted dates like Feb 31st, and rightly so. But this seems 
> to me to be like our own version of the same problem.

It seems to me that the easiest solution would be to forbid \x?? escape
sequences where it's greater than \x7F for UTF-8 server encodings.
Instead introduce a \u escape for specifying the unicode character
directly. Under the basic principle that any escape sequence still has
to represent a single character. The result can be multiple bytes, but
you don't have to check for consistancy anymore.

Have a nice day,
-- 
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.