RE: [EXTERNAL] Re: Windows Application Issues | PostgreSQL | REF # 48475607

Hi Thomas,

What questions do you have? Could you please list them clearly so that Vishwa could help to answer?

NOTE: this email is plain text format, not easy to read. And also the previous email content usually is not included in the latest email, we only could see the most latest one.

Thanks!
Haifang

-----Original Message-----
From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Sent: Friday, May 17, 2024 10:57 PM
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Haifang Wang (Centific Technologies Inc) <v-haiwang(at)microsoft(dot)com>; Vishwa Deepak <Vishwa(dot)Deepak(at)microsoft(dot)com>; pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: [EXTERNAL] Re: Windows Application Issues | PostgreSQL | REF # 48475607

On Sat, May 18, 2024 at 5:47 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> > With answers to those questions we might be able to ship some nice
> > built-in translations to get users out of this jam. If there are
> > issues on those points, we might have to face some questions about
> > what the encoding is of the "Turkish_Türkiye.1254" string itself,
> > which is tricky for us for technical reasons, among other problems...
> > not sure.
>
> TBH, my idea of how this should go was to *not* ship any built-in
> translations, or indeed any translation file at all (so I didn't like
> your moving some existing hacks into that file). If we approach it
> like that, then individual users who hit this problem are responsible
> for creating their own translation file, which will automatically use
> whatever is the locally-appropriate encoding. Sure, it's less
> transparent for affected users, but it will work for them which other
> approaches might not; and evidence so far is that there's not a huge
> number of affected users.

Hmm, yeah I guess we could just ship a patch like what I posted already, and let users figure out what works. I would still like to know the answer to those questions so we can offer good advice. If the answers are all yes then I think we can say "the file is in encoded in ASCII; use wildcards to deal with any legacy non-ASCII locale names on the left, and use BCP47 names on the right" and begin expunging the bad old names from our universe.