On Sat, 22 Jan 2005 17:09:42 -0500, Tom Lane <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq