Re: different sort order in windows and linux version
От
Tomi NA
Тема
Re: different sort order in windows and linux version
Дата
Msg-id
d487eb8e0607021414w496833f5t848ba4dc4cd7fa6a@mail.gmail.com
Ответ на
Список
Дерево обсуждения
different sort order in windows and linux version Dragan Matic <mlists@panforma.co.yu>
Re: different sort order in windows and linux version Martijn van Oosterhout <kleptog@svana.org>
Re: different sort order in windows and linux version "Tomi NA" <hefest@gmail.com>
Re: different sort order in windows and linux version Martijn van Oosterhout <kleptog@svana.org>
Re: different sort order in windows and linux version "Tomi NA" <hefest@gmail.com>
Re: different sort order in windows and linux version Tom Lane <tgl@sss.pgh.pa.us>
Re: different sort order in windows and linux version Martijn van Oosterhout <kleptog@svana.org>
Re: different sort order in windows and linux version Karsten Hilbert <Karsten.Hilbert@gmx.net>
Re: different sort order in windows and linux version Agent M <agentm@themactionfaction.com>
Re: different sort order in windows and linux version Martijn van Oosterhout <kleptog@svana.org>
Re: different sort order in windows and linux version "Tomi NA" <hefest@gmail.com>
Re: different sort order in windows and linux version Dragan Matic <mlists@panforma.co.yu>
Re: different sort order in windows and linux version Tom Lane <tgl@sss.pgh.pa.us>
Re: different sort order in windows and linux version Martijn van Oosterhout <kleptog@svana.org>
Re: different sort order in windows and linux version Dragan Matic <mlists@panforma.co.yu>
On 7/2/06, Agent M wrote: > Certain Japanese characters cannot make a reliable round-trip through > Unicode. ICU uses UTF-16 as its store, so the Japanese folks won't be > happy with an ICU-only solution. However, it would still be of great Could you explain what you mean and what's special with those characters? > benefit to allow ICU to handle as much as possible, leaving the string > encodings to the encoding experts. > > At the very least, it would be great to have ICU to handle encoding on > a per-column basis (perhaps extending the text datatype with encoding > info). Perhaps this would be a decent stopgap solution? The backend > protocol would also need a version bump- currently, it converts all > strings to a single encoding. Could you give an example of what that would look like in your opinion? I was thinking more along the lines of a setting in pg_hba.conf where the server uses or does not use something like ICU...at least as an intermediate solution. Adding a "LOCALE" clause to a column definition (similar to the "ENCODING" clause of the "CREATE DATABASE" statement) would solve most (not all) problems with a default locale. There still might be some non-deterministic behaviour with operations between strings in different locales but it's far from a showstopper. t.n.a.
В списке pgsql-general по дате отправления
От: Alexander Farber
Дата: