On Thu, Feb 26, 2004 at 09:16:03AM -0500, Tom Lane wrote: > Karel Zak <[EMAIL PROTECTED]> writes: > > I think possible solution is special function used ORDER BY clause > > which knows to switch by safe way to wanted locales, convert string by > > strxfrm() and switch back to backend locales. > > This function breaks the whole backend if an elog() failure occurs while
Fixed by sigsetjmp(Warn_restart..). I hope it's more safe now. > it's got the wrong locale set. I believe it would also be remarkably > slow --- doesn't setlocale() involve reading a new locale definition You're right, it's slow. But sometimes is more important that it works and not all queries work with thousands records like my test below. > I think the ultimate solution to our multi-locale problems will have to > involve abandoning the C library's support functions and writing locale > support that allows multiple locale-defining structures referenced by Agree. But as you said it's huge task and I think if it won't implement in 7.5 we can add nls_string() to the contrib tree. BTW, nls_string() is "product" of Czech database list where Oracle users have still problems with PostgreSQL ;-) Latest version: ftp://ftp2.zf.jcu.cz/users/zakkr/pg/postgresql-nls-string-0.52.tar.gz Note, I add "CC:" to pgsql-general, maybe it's interesting for some normal users too. Tests: # SELECT count(*) FROM nlstest; count -------- 100000 # SELECT data FROM nlstest ORDER BY upper(data) DESC LIMIT 1; Time: 1213.87 ms # SELECT data FROM nlstest ORDER BY nls_string(data, 'en_US') LIMIT 1; Time: 4269.00 ms Karel -- Karel Zak <[EMAIL PROTECTED]> http://home.zf.jcu.cz/~zakkr/ ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org