Re: Collation rules and multi-lingual databases

From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Collation rules and multi-lingual databases
Date: 2003-08-23 01:29:08
Message-ID: 20030822182337.S2037-100000@megazone.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 22 Aug 2003, Tom Lane wrote:

> Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Larry Rosenman 2003-08-23 02:23:57 strerror_r and gethostbyname_r?
Previous Message Tom Lane 2003-08-22 23:53:48 Re: Collation rules and multi-lingual databases