Re: Allow to_date() and to_timestamp() to accept localized names
От | Tom Lane |
---|---|
Тема | Re: Allow to_date() and to_timestamp() to accept localized names |
Дата | |
Msg-id | 12376.1583705032@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Allow to_date() and to_timestamp() to accept localized names (James Coleman <jtc331@gmail.com>) |
Ответы |
Re: Allow to_date() and to_timestamp() to accept localized names
|
Список | pgsql-hackers |
James Coleman <jtc331@gmail.com> writes: > So just to confirm I understand, that implies that the issue is solely that > only the utf8 tr_TR set is installed by default on this machine, and the > iso-8859-9 set is a hard requirement (that is, the test is explicitly > testing a codepath that generates utf8 results from a non-utf8 source)? It's not "explicitly" testing that; the fact that "tr_TR" is treated as "tr_TR.iso88599" is surely an implementation artifact. (On macOS, some experimentation shows that "tr_TR" is treated as "tr_TR.UTF-8".) But yeah, I think it's intentional that we want the codeset translation path to be exercised here on at least some platforms. > If in fact Ubuntu doesn't install this locale by default, then is this a > caveat we should add to developer docs somewhere? It seems odd to me that > I'd be the only one encountering it, but OTOH I would have thought this a > fairly vanilla install too... Not sure. The lack of prior complaints points to this not being a common situation. It does seem weird that they'd set things up so that "tr_TR.utf8" exists but not "tr_TR"; even if that's not an outright packaging mistake, it seems like a POLA violation from here. regards, tom lane
В списке pgsql-hackers по дате отправления: