Re: TM format can mix encodings in to_char()
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2019-04-21T14:21:19Z
Lists: pgsql-hackers
Andrew Dunstan <andrew.dunstan@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.) regards, tom lane
Commits
-
Repair assorted issues in locale data extraction.
- e899df6a24f6 11.3 landed
- c0bafc5e58c5 9.4.22 landed
- 7c02c3f75604 10.8 landed
- 74589026f79f 9.5.17 landed
- 1e5de96629f6 9.6.13 landed
- 7ad1cd31bfcb 12.0 landed