Peter Eisentraut wrote:
Am Sonntag, 14. August 2005 23:48 schrieb Tom Lane:
Yeah, but don't we already have some code for that (or, actually, the
reverse direction) in initdb? It's probably not perfect, but it'd be
a lot better than crashing.
The reverse direction is a lot simpler
Bruce Momjian pgman@candle.pha.pa.us writes:
Is there a TODO here?
Yeah:
* Fix problems with wrong runtime encoding conversion for NLS message files
One thing that occurred to me is that we might be able to simplify the
problem by adopting a project standard that all NLS message files shall
be
Am Dienstag, 9. August 2005 04:51 schrieb Tom Lane:
which leads to the question why aren't we using
bind_textdomain_codeset() to tell gettext what character set it should
produce?
That would probably require us to solve the question on how to translate
PostgreSQL encoding names to OS encoding
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Dienstag, 9. August 2005 04:51 schrieb Tom Lane:
which leads to the question why aren't we using
bind_textdomain_codeset() to tell gettext what character set it should
produce?
That would probably require us to solve the question on how to
Am Sonntag, 14. August 2005 23:48 schrieb Tom Lane:
Yeah, but don't we already have some code for that (or, actually, the
reverse direction) in initdb? It's probably not perfect, but it'd be
a lot better than crashing.
The reverse direction is a lot simpler because we know the set of possible
Qingqing Zhou [EMAIL PROTECTED] writes:
Yeah, it is not a very clean solution. Do you mean the general problem is
prevent recursive error reporting because of the error in transalting error
message?
I put the image of the reporting email here:
http://www.cs.toronto.edu/~zhouqq/encode.jpg
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
I wrote:
This does not look real easy to fix. Who's up for reimplementing
gettext and a few other pieces from scratch?
However, I did find
http://gnu.miscellaneousmirror.org/software/libc/manual/html_node/Charset-conversion-in-gettext.html#Charset-conversion-in-gettext
which leads to the
As this thread reports (some sever messages are in Chinese):
http://archives.postgresql.org/pgsql-bugs/2005-07/msg00247.php
a SQL grammar error could crash the error stack.
My explaination is that select; incurs a parse error and this error
message is
supposed to be translated into your
Qingqing Zhou [EMAIL PROTECTED] writes:
As this thread reports (some sever messages are in Chinese):
http://archives.postgresql.org/pgsql-bugs/2005-07/msg00247.php
a SQL grammar error could crash the error stack.
Hmm, I thought we had fixed that years ago.
To fix this, we just change
Tom Lane [EMAIL PROTECTED] writes
This is a really ugly solution ... and I don't think it solves the
general problem anyway, since this isn't the only possible error message.
Yeah, it is not a very clean solution. Do you mean the general problem is
prevent recursive error reporting because
11 matches
Mail list logo
