Skip site navigation (1) Skip section navigation (2)

Re: ORDER BY different locales

From: Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ORDER BY different locales
Date: 2004-02-26 14:45:43
Message-ID: 20040226144543.GC9785@zf.jcu.cz (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
On Thu, Feb 26, 2004 at 09:16:03AM -0500, Tom Lane wrote:
> Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> 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

 I  don't think  so. There  is setlocale()  to  original locales  before
 elog(). But important  is idea of  this function. We can rewrite  it to
 fix some minor problems...

> it's got the wrong locale set.  I believe it would also be remarkably
> slow --- doesn't setlocale() involve reading a new locale definition
> file from whereever those are stored?

 Yes, speed can be problem. I will test it. But I hope libc read locales
 one time  only. The common usage  is with  SELECT where you  apply same
 locales to all lines of result.

> I think the ultimate solution to our multi-locale problems will have to
> involve abandoning the C library's support functions and writing locale

 Yes, but I think nls_string() is nice solution for now. Butter than say
 "no way"... :-)

    Karel

-- 
 Karel Zak  <zakkr(at)zf(dot)jcu(dot)cz>
 http://home.zf.jcu.cz/~zakkr/

In response to

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2004-02-26 14:57:03
Subject: log_line_info
Previous:From: Tom LaneDate: 2004-02-26 14:16:03
Subject: Re: ORDER BY different locales

pgsql-general by date

Next:From: Keith BottnerDate: 2004-02-26 15:05:06
Subject: PL/pgSQL debugger
Previous:From: Karam ChandDate: 2004-02-26 14:18:57
Subject: Index Information

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group