Re: Locale agnostic unicode text
От | Dawid Kuroczko |
---|---|
Тема | Re: Locale agnostic unicode text |
Дата | |
Msg-id | 758d5e7f05012307547159e76@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Locale agnostic unicode text (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Locale agnostic unicode text
|
Список | pgsql-hackers |
On Sat, 22 Jan 2005 17:09:42 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > This time setlocale() was needed to get the behaviour > > I needed (database initdb'ed to 'C', my order set to 'pl_PL', > > or whatever locale I need at given moment). > I would imagine that the performance is spectacularly awful :-(. > Have you benchmarked it? A large sort on a unitext column, > for instance, would be revealing. True. Yet it would be still better than nothing ("C"). Actually I was thinking that maybe functional indexes could be used to boost the speed (at least for ordering). > > ...but I would like to force ORDER BY using operators > > provided by me without this 'USING <' clause. > Hmm, the existence of the default btree operator class should be > sufficient. If You (or anyone) could try that SQL file and try to find missing clause... :) I guess that the case is that DOMAIN unitext is not quite another type, so text's default operators sometimes take precedence over unitext's own. :) > > CREATE OR REPLACE FUNCTION lower(unitext) RETURNS unitext AS $$ > > utf8::decode($_[0]); > > return lc($_[0]); > > $$ LANGUAGE plperlu IMMUTABLE; > > AFAIK upper/lower cannot be considered to be locale-independent > (see Turkish I/i business for a counterexample). I imagine it is not possible to make 'one size fits all' lower(), yet perl's uc()/lc() in my opinion for some cases is still better than choosing one locale or using "C" locale. Regards, Dawid
В списке pgsql-hackers по дате отправления: