Re: prevent encoding conversion recursive error - Mailing list pgsql-patches

From Tom Lane
Subject Re: prevent encoding conversion recursive error
Date
Msg-id 11458.1123554854@sss.pgh.pa.us
Whole thread Raw
In response to Re: prevent encoding conversion recursive error  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: prevent encoding conversion recursive error  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
I wrote:
> ...real problem is that gettext() has not been told the correct character
> set to convert messages to.

> ISTM we've seen this issue before and Peter had an idea how to fix it,
> but I forget the details.  Peter?

A little bit of digging in the list archives located
http://archives.postgresql.org/pgsql-hackers/2003-11/msg01299.php
in which Peter opines

: - lc_collate and lc_ctype need to be held fixed in the entire cluster.
:
: - Gettext relies on iconv character set conversion, which relies on
:   lc_ctype, which leads to a complete screw-up in the server because of
:   the previous item.

which seems to fit with my observation: the message texts are being
converted to the cluster's original encoding rather than the encoding
that's active in the current database.

This does not look real easy to fix.  Who's up for reimplementing
gettext and a few other pieces from scratch?

There is a separate line of thought here, which is that we are unlikely
ever to get this completely perfect, and so it'd be good if errors
during error processing didn't lead to recursion and PANIC.  I don't
have an idea how to solve that one either.

            regards, tom lane

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: prevent encoding conversion recursive error
Next
From: Tom Lane
Date:
Subject: Re: prevent encoding conversion recursive error