On 4/21/19 10:21 AM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.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.) > >
Test above works as expected with the patch, see attached. This is from jacana. LMK if you want more tests run before I blow the test instance away cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
select getdatabaseencoding(); getdatabaseencoding --------------------- UTF8 (1 row) set lc_time to 'Turkish_Turkey.1254'; SET select to_char(date '2010-02-01','DD TMMON YYYY'); to_char ------------- 01 ŞUB 2010 (1 row)
