Re: locale

From: Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org>
To: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, <pgman(at)candle(dot)pha(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: locale
Date: 2004-04-08 07:31:57
Message-ID: Pine.LNX.4.44.0404080922421.4551-100000@zigo.dhs.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 8 Apr 2004, Tatsuo Ishii wrote:

> > The tables in template1 in encoding E1 are compied into the new database
> > in encoding E2. Not all encodings are compatable, so you can't even
> > convert from E1 to E2.
>
> In this case you just set your terminal encoding to E1, then SELECT
> the table. Point is you do not use set client_encoding or \encoding
> command. This will work as long as both E1 and E2 are single byte
> encodings.

That is not a solution.

As you said, it does not even work for all encodings. If the database is
in Latin1 I'd expect that the strings in the table are just latin1 and not
something else. And for some multibyte encodings that something else might
not just be the wrong characters but an invalid string (think utf-8).

I can also imagine the indexes being wrong when you keep the encoding of
tables when you create a new database. Since the same character can be
represented differently, the sort order also changes if you try to
interpret something with another encoding then what the compare operator
think it is. That makes the index invalid.

It's simply broken if you ask me.

--
/Dennis Björklund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gaetano Mendola 2004-04-08 11:49:59 idle in transaction with JDBC interface
Previous Message Tatsuo Ishii 2004-04-08 07:22:10 Re: locale