Re: Collation rules and multi-lingual databases - Mailing list pgsql-hackers

From Stephan Szabo
Subject Re: Collation rules and multi-lingual databases
Date
Msg-id 20030822215516.T6822-100000@megazone.bigpanda.com
Whole thread Raw
In response to Re: Collation rules and multi-lingual databases  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Responses Re: Collation rules and multi-lingual databases
List pgsql-hackers
On Fri, 22 Aug 2003, Stephan Szabo wrote:

> On Fri, 22 Aug 2003, Tom Lane wrote:
>
> > Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> > > On 22 Aug 2003, Greg Stark wrote:
> > >> If it's deemed a reasonable approach and nobody has any fatal flaws then I
> > >> expect it would be useful to put in the contrib directory?
> >
> > > I'm not sure that ERROR if the locale cannot be put back is sufficient
> > > (although that case should be rare or non-existant).
> >
> > A bigger risk is that something might elog(ERROR) while you have the
> > "wrong" locale set, denying you the chance to put back the right one.
> > I think this code is not nearly paranoid enough about how much it does
> > while the wrong locale is set.
>
> True, there are calls to palloc, elog, etc inside there, although the elog
> could be removed.

Since most of that work is for an exceptional case, maybe it'd be safer
(although slower) to structure the function as

setlocale
call strxfrm (and that's it)
setlocale back
if there wasn't enough spacemake a new buffersetlocalecall strxfrm (and that's it)setlocale back

Probably putting the sl/strxfrm/sl into its own function.



pgsql-hackers by date:

Previous
From: Robert Creager
Date:
Subject: Header files installed for contrib modules?
Next
From: Larry Rosenman
Date:
Subject: Re: strerror_r and gethostbyname_r?