Re: Multibyte encoding vs. SQL_ASCII vs. locales and European languages - Mailing list pgsql-general

From Einar Karttunen
Subject Re: Multibyte encoding vs. SQL_ASCII vs. locales and European languages
Date
Msg-id 20020129172925.GA20118@shellak.helsinki.fi
Whole thread Raw
In response to Re: Multibyte encoding vs. SQL_ASCII vs. locales and European languages  (Frank Joerdens <frank@joerdens.de>)
Responses Re: Multibyte encoding vs. SQL_ASCII vs. locales and European languages  (Frank Joerdens <frank@joerdens.de>)
List 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 by date:

Previous
From: Stephan Szabo
Date:
Subject: Re: unique & update
Next
From: Frank Joerdens
Date:
Subject: Re: Multibyte encoding vs. SQL_ASCII vs. locales and European languages