Re: Bug in UTF8-Validation Code?
От | Martijn van Oosterhout |
---|---|
Тема | Re: Bug in UTF8-Validation Code? |
Дата | |
Msg-id | 20070318113622.GA5722@svana.org обсуждение исходный текст |
Ответ на | Re: Bug in UTF8-Validation Code? (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Bug in UTF8-Validation Code?
Re: Bug in UTF8-Validation Code? |
Список | 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.
В списке pgsql-hackers по дате отправления: