From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org> |
Cc: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgman(at)candle(dot)pha(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: locale |
Date: | 2004-04-08 13:56:06 |
Message-ID: | 13283.1081432566@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org> writes:
> 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.
See my previous point: the index does not actually fail, in our current
implementation, because strcoll() is unaffected by the database's
encoding setting. You'd be likely to have trouble with I/O translation
and with other encoding-dependent operations like upper()/lower() ...
but not with indexes.
> It's simply broken if you ask me.
It's certainly ungood, but I don't think we can materially improve
things without a fundamental rewrite along the lines of Peter's proposal
to support per-column locale/encoding. Database-level settings are
simply the wrong tool for this.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dennis Bjorklund | 2004-04-08 14:16:11 | Re: locale |
Previous Message | pgsql | 2004-04-08 13:49:38 | Re: PostgreSQL configuration |