Dennis Bjorklund <db@zigo.dhs.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