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 20030822182337.S2037-100000@megazone.bigpanda.com
Whole thread Raw
In response to Re: Collation rules and multi-lingual databases  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Collation rules and multi-lingual databases
Re: Collation rules and multi-lingual databases
List pgsql-hackers
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.

> > Unless something else
> > in the system resets the locale, after your transaction rolls back, you're
> > in a dangerous state.  I'd think FATAL would be better.
>
> I'd go so far as to make it a critical section --- that ensures that any
> ERROR will be turned to FATAL, even if it's in a subroutine you call.

I didn't know we could do that, could be handy, although the comments
imply that it turns into PANIC which would force a complete restart.  Then
again, it's better than a corrupted database.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Collation rules and multi-lingual databases
Next
From: Larry Rosenman
Date:
Subject: strerror_r and gethostbyname_r?