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

On Sun, Mar 8, 2020 at 6:03 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> James Coleman <jtc331(at)gmail(dot)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.
>

I idly wonder if there could/should be some tests for the implicit case,
some explicitly testing the codeset translation (if possible), and some
testing the explicit utf8 case...but I don't know enough about this area to
push for anything.

> > 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
>

All right. I downloaded an Ubuntu 18.04.3 server VM from OSBoxes, and it
had very few locales installed by default...so that wasn't all that helpful.

I think at this point I'll just leave this as a mystery, much as I hate
that.

James