Re: Allow to_date() and to_timestamp() to accept localized names - Mailing list pgsql-hackers

From James Coleman
Subject Re: Allow to_date() and to_timestamp() to accept localized names
Date
Msg-id CAAaqYe8-PTBympzUioLE8xn_CeK4c16YKDq91CLD43kDDC98GQ@mail.gmail.com
Whole thread Raw
In response to Re: Allow to_date() and to_timestamp() to accept localized names  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Allow to_date() and to_timestamp() to accept localized names  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, Mar 7, 2020 at 9:31 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
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

Hmm, when I grep the locales I see `tr_TR.utf8` in the output. I assume the utf8 version is acceptable? Or is there a non-utf8 variant?

Thanks,
James

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Allow to_date() and to_timestamp() to accept localized names
Next
From: David Fetter
Date:
Subject: Re: range_agg