Re: Allow to_date() and to_timestamp() to accept localized names
От | James Coleman |
---|---|
Тема | Re: Allow to_date() and to_timestamp() to accept localized names |
Дата | |
Msg-id | CAAaqYe8-PTBympzUioLE8xn_CeK4c16YKDq91CLD43kDDC98GQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Allow to_date() and to_timestamp() to accept localized names (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Allow to_date() and to_timestamp() to accept localized names
|
Список | 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 по дате отправления: