Re: Multibyte encoding vs. SQL_ASCII vs. locales and European languages

On Tue, Jan 29, 2002 at 07:29:25PM +0200, Einar Karttunen wrote:
> 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(at)joerdens(dot)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?

That's what I meant. Getting the sort order right would require you to
use locales (Or some latin encoding? Does any one of the latin 1-5 imply
the difference between Scandinavian and German umlaut ordering?). I
didn't say I wanted to do without locales and still get the sort order
right (did it sound that way?).

Regards, Frank