Re: Multibyte encoding vs. SQL_ASCII vs. locales and European languages
От | Einar Karttunen |
---|---|
Тема | Re: Multibyte encoding vs. SQL_ASCII vs. locales and European languages |
Дата | |
Msg-id | 20020129172925.GA20118@shellak.helsinki.fi обсуждение исходный текст |
Ответ на | Re: Multibyte encoding vs. SQL_ASCII vs. locales and European languages (Frank Joerdens <frank@joerdens.de>) |
Ответы |
Re: Multibyte encoding vs. SQL_ASCII vs. locales and European languages
|
Список | pgsql-general |
On 29.01.02 18:00 +0100(+0000), Frank Joerdens wrote: > On Tue, Jan 29, 2002 at 10:56:37AM -0500, Tom Lane wrote: > > Frank Joerdens <frank@joerdens.de> writes: > > > Multibyte support is mainly recommended for character sets that don't > > > fit into a single byte (Chinese, Japanese, Korean), and locale support > > > is said to be mostly sufficient for European languages . . . what escapes > > > me is why I should bother with either of these when SQL_ASCII works just > > > fine with my mostly German users. I must be missing something, right? > > > > Sort ordering of non-7-bit-ASCII characters? upper/lower case > > conversions that work as expected? locale-aware formatting options > > in to_char and friends? > > Hm, yes. I overlooked that - and it *would* be useful (though no one's > complained so far that their entries beginning with an umlaut don't > appear in the list a the appropriate place, which is presumably partly > due to the fact that not that many German words or names have an umlaut > as their first character). > And how do we know, how the umlauts are supposed to be alphabetically ordered without locales? Should Ä be between A and B as in Germany or between Å and Ö in the end of the alphabet as in Scandinavia? So the solution would be to have tables for each unibyte locale specifying the sort order... - Einar Karttunen
В списке pgsql-general по дате отправления: