Re: invalidly encoded strings
От | Tom Lane |
---|---|
Тема | Re: invalidly encoded strings |
Дата | |
Msg-id | 3702.1189433070@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: invalidly encoded strings (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: invalidly encoded strings
|
Список | pgsql-hackers |
Andrew Dunstan <andrew@dunslane.net> writes: > The reason we are prepared to make an exception for Unicode is precisely > because the code point maps to an encoding pattern independently of > architecture, ISTM. Right --- there is a well-defined standard for the numerical value of each character in Unicode. And it's also clear what to do in single-byte encodings. It's not at all clear what the representation ought to be for other multibyte encodings. A direct transliteration of the byte sequence not only has endianness issues, but will have a weird non-dense set of valid values because of the restrictions on valid multibyte characters. Given that chr() has never before behaved sanely for multibyte values at all, extending it to Unicode code points is a reasonable extension, and throwing error for other encodings is reasonable too. If we ever do come across code-point standards for other encodings we can adopt 'em at that time. regards, tom lane
В списке pgsql-hackers по дате отправления: