On Thu, Sep 01, 2005 at 05:48:55PM +0200, Peter Eisentraut wrote:
> Am Sonntag, 21. August 2005 01:48 schrieb Tom Lane:
> > 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 in UTF8, period. The
Am Sonntag, 21. August 2005 01:48 schrieb Tom Lane:
> 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 in UTF8, period. Then we only have one encoding name to figure out
> rather than N. Maybe thi
Bruce Momjian 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 in UTF8, period. The
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 simpl
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 possib
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 ho
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 enco
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 q
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.post
"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/enco
"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 b
"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 cha
12 matches
Mail list logo
