Horton

Re: Allow to_date() and to_timestamp() to accept localized names

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: James Coleman <jtc331@gmail.com>
Cc: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Mark Dilger <mark.dilger@enterprisedb.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Arthur Zakirov <zaartur@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-03-08T02:31:17Z
Lists: pgsql-hackers 
James Coleman <jtc331@gmail.com> writes:
> On master with a clean build (and configure re-run) and a fresh init-db,
> I'm seeing the collate.linux.utf8 test fail with the attached diff.

 -- to_char
 SET lc_time TO 'tr_TR';
+ERROR:  invalid value for parameter "lc_time": "tr_TR"
 SELECT to_char(date '2010-02-01', 'DD TMMON YYYY');

Looks like you may not have Turkish locale installed?  Try

locale -a | grep tr_TR

If you don't see "tr_TR.utf8" or some variant spelling of that,
the collate.linux.utf8 test is not gonna pass.  The required
package is probably some sub-package of glibc.

A workaround if you don't want to install more stuff is to run the
regression tests in C locale, so that that test script gets skipped.

			regards, tom lane

Commits

  1. Allow to_date/to_timestamp to recognize non-English month/day names.

  2. Clean up formatting.c's logic for matching constant strings.

  3. Implement standard datetime parsing mode

  4. Repair assorted issues in locale data extraction.