From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
Cc: | Juan José Santamaría Flecha <juanjo(dot)santamaria(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: TM format can mix encodings in to_char() |
Date: | 2019-04-21 14:21:19 |
Message-ID: | 18695.1555856479@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
> On 4/21/19 12:28 AM, Tom Lane wrote:
>> I don't have any way to test this on Windows, so could somebody
>> do that? Manually running the Turkish test cases ought to be enough.
> How does one do that? Just set a Turkish locale?
Try variants of the original test case. For instance, in a UTF8
database,
regression=# show server_encoding ;
server_encoding
-----------------
UTF8
(1 row)
regression=# SET lc_time TO 'tr_TR.iso88599';
SET
regression=# SELECT to_char(date '2010-02-01', 'DD TMMON YYYY');
to_char
--------------
01 ŞUB 2010
(1 row)
Unpatched, I get an error about invalid data. Now, this is in
a Linux machine, and you'll have to adapt it for Windows --- at
least change the LC_TIME setting. But the idea is to get out some
non-ASCII strings from an LC_TIME setting that names an encoding
different from the database's.
(I suspect you'll find that the existing code works fine on
Windows, it's only the first version(s) of this patch that fail.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2019-04-21 16:59:03 | Re: [HACKERS] Weaker shmem interlock w/o postmaster.pid |
Previous Message | Andrew Dunstan | 2019-04-21 13:25:48 | Re: TM format can mix encodings in to_char() |