Magnus Hagander wrote:
Peter Eisentraut wrote:
Magnus Hagander wrote:
However, one question: The comment currently says it's harmless to do
this on non-windows platforms. Does this still hold true?
Yes, the non-WIN32 code path appears to be the same, still. But the
ifdef WIN32 part we don't
Hiroshi Inoue wrote:
Magnus Hagander wrote:
Peter Eisentraut wrote:
Magnus Hagander wrote:
However, one question: The comment currently says it's harmless to do
this on non-windows platforms. Does this still hold true?
Yes, the non-WIN32 code path appears to be the same, still. But the
Hiroshi Inoue wrote:
Hiroshi Inoue wrote:
Magnus Hagander wrote:
Hiroshi Inoue wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi, is this patch still needed?
Yes though it should be slightly changed now.
In what way should it be changed?
One is already committed by you.
Magnus Hagander wrote:
However, one question: The comment currently says it's harmless to do
this on non-windows platforms. Does this still hold true?
Yes, the non-WIN32 code path appears to be the same, still. But the
ifdef WIN32 part we don't want, because that presumes something about
Peter Eisentraut wrote:
Magnus Hagander wrote:
However, one question: The comment currently says it's harmless to do
this on non-windows platforms. Does this still hold true?
Yes, the non-WIN32 code path appears to be the same, still. But the
ifdef WIN32 part we don't want, because that
Magnus Hagander wrote:
Peter Eisentraut wrote:
Magnus Hagander wrote:
However, one question: The comment currently says it's harmless to do
this on non-windows platforms. Does this still hold true?
Yes, the non-WIN32 code path appears to be the same, still. But the
ifdef WIN32 part we don't
Hiroshi Inoue wrote:
Magnus Hagander wrote:
Hiroshi Inoue wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi, is this patch still needed?
Yes though it should be slightly changed now.
In what way should it be changed?
One is already committed by you.
[COMMITTERS] pgsql: Use the
Hiroshi Inoue wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi, is this patch still needed?
Yes though it should be slightly changed now.
In what way should it be changed?
//Magnus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Magnus Hagander wrote:
Hiroshi Inoue wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi, is this patch still needed?
Yes though it should be slightly changed now.
In what way should it be changed?
One is already committed by you.
[COMMITTERS] pgsql: Use the new text domain names
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi, is this patch still needed?
Yes though it should be slightly changed now.
*set lc_messages does not work* issue isn't directly related to this
issue.
Though I'm not sure how we can test it, I can provide test results
like the attached one.
Hi.
My swift attack test was the MinGW environment.
But, Inoue-san suggestion.
1. MinGW+gcc build
HIROSHI=# set LC_TIME=Ja;
SET
HIROSHI=# select to_char(now(),'TMDay');
to_char
-
日曜日
(1 行)
HIROSHI=# set LC_TIME='Japan';
SET
HIROSHI=# select to_char(Now(),'TMDay');
to_char
-
日曜日
Hiroshi, is this patch still needed?
---
Hiroshi Inoue wrote:
Magnus Hagander wrote:
On 25 nov 2008, at 05.00, Tom Lane t...@sss.pgh.pa.us wrote:
Hiroshi Inoue in...@tpf.co.jp writes:
Tom Lane wrote:
If that's
Bruce Momjian br...@momjian.us writes:
Hiroshi, is this patch still needed?
This patch is for a problem that's entirely separate from the LC_TIME
issue, if that's what you were wondering.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Bruce Momjian wrote:
Hiroshi, is this patch still needed?
Yes though it should be slightly changed now.
*set lc_messages does not work* issue isn't directly related to this
issue.
regards,
Hiroshi Inoue
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Hiroshi Inoue wrote:
I think the thing us that as long as the encodings are compatible
(latin1 with different names for example) it worked fine.
In any case I think the problem is that gettext is
looking at a setting that is not what we are looking at. Particularly
with the 8.4 changes to
Magnus Hagander wrote:
Hiroshi Inoue wrote:
I think the thing us that as long as the encodings are compatible
(latin1 with different names for example) it worked fine.
In any case I think the problem is that gettext is
looking at a setting that is not what we are looking at. Particularly
Magnus Hagander wrote:
On 25 nov 2008, at 05.00, Tom Lane [EMAIL PROTECTED] wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Tom Lane wrote:
If that's true then this code is presently broken for *every* locale
under Windows, not only Japanese.
Maybe there are a few languages/countires where
Hiroshi Inoue wrote:
Hi Magnus and all,
Magnus Hagander wrote:
Log Message:
---
Explicitly bind gettext() to the UTF8 locale when in use.
This is required on Windows due to the special locale
handling for UTF8 that doesn't change the full environment.
Thanks to this change
Magnus Hagander wrote:
Hiroshi Inoue wrote:
Hi Magnus and all,
Magnus Hagander wrote:
Log Message:
---
Explicitly bind gettext() to the UTF8 locale when in use.
This is required on Windows due to the special locale
handling for UTF8 that doesn't change the full environment.
Hiroshi Inoue wrote:
Magnus Hagander wrote:
Hiroshi Inoue wrote:
Hi Magnus and all,
Magnus Hagander wrote:
Log Message:
---
Explicitly bind gettext() to the UTF8 locale when in use.
This is required on Windows due to the special locale
handling for UTF8 that doesn't change the
Magnus Hagander [EMAIL PROTECTED] writes:
Hiroshi Inoue wrote:
because Shift_JIS isn't allowed as a server encoding. So
the Japanese Windows native message encoding Shift_JIS never
matches the server encoding EUC_JP and a conversion between
Shitt_jis and EUC_JP is necessarily needed.
Ah, so
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Hiroshi Inoue wrote:
because Shift_JIS isn't allowed as a server encoding. So
the Japanese Windows native message encoding Shift_JIS never
matches the server encoding EUC_JP and a conversion between
Shitt_jis and EUC_JP is necessarily
Hiroshi Inoue [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm not following this either. If the patch is really necessary then it
seems it must be working around a bug in the Windows version of gettext,
ie failure to distinguish CP932 from CP20932. Is that correct?
I'm afraid I don't
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm not following this either. If the patch is really necessary then it
seems it must be working around a bug in the Windows version of gettext,
ie failure to distinguish CP932 from CP20932. Is that correct?
I'm
Hiroshi Inoue [EMAIL PROTECTED] writes:
Tom Lane wrote:
If that's true then this code is presently broken for *every* locale
under Windows, not only Japanese.
Maybe there are a few languages/countires where 2 encodings are
widely used.
UTF8 vs Latin-N? In any case I think the problem is
On 25 nov 2008, at 05.00, Tom Lane [EMAIL PROTECTED] wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Tom Lane wrote:
If that's true then this code is presently broken for *every* locale
under Windows, not only Japanese.
Maybe there are a few languages/countires where 2 encodings are
widely
26 matches
Mail list logo