From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
cc: "Haifang Wang (Centific Technologies Inc)" <v-haiwang@microsoft.com>,
        Vishwa Deepak <Vishwa.Deepak@microsoft.com>,
        "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
Subject: Re: [EXTERNAL] Re: Windows Application Issues | PostgreSQL | REF #
 48475607
In-reply-to: 
 <CA+hUKG+oS+rriPvML+j6mZgCkJDsGP9bP7qopVxSLeTWsAOtsA@mail.gmail.com>
References: 
 <PH8PR21MB390263C479B81A1B7330E744E5182@PH8PR21MB3902.namprd21.prod.outlook.com>
 <PH8PR21MB3902F334A3174C54058F792CE5182@PH8PR21MB3902.namprd21.prod.outlook.com>
 <CA+hUKG+b_XqMZ6xkFhMCEwLXbGSN1rDYYY-En8MgFe81auRAAg@mail.gmail.com>
 <PH8PR21MB39022E5B54CE6E03E194B30FE5E22@PH8PR21MB3902.namprd21.prod.outlook.com>
 <CA+hUKGKrzGnCW3MoVC7gayHCtJQPEJKgpfQWD6c7eUvFp+ac+A@mail.gmail.com>
 <PH8PR21MB39027F1F4EAFEAE33EB4BA39E5E22@PH8PR21MB3902.namprd21.prod.outlook.com>
 <CA+hUKG+GUcSzk7UwvuLr4p84BQV8k2xvVAjToW=fQ5rCrciJ4A@mail.gmail.com>
 <872239.1715641638@sss.pgh.pa.us>
 <CA+hUKGJJgyc9xg+g_8_jPUV08Kr0NFdgq2_H9mm7-eZd7YVRQg@mail.gmail.com>
 <PH8PR21MB3902402C3C3C20DD8CB40AFFE5EC2@PH8PR21MB3902.namprd21.prod.outlook.com>
 <PH8PR21MB39027671C218DE448D8C091CE5EE2@PH8PR21MB3902.namprd21.prod.outlook.com>
 <CA+hUKG+oS+rriPvML+j6mZgCkJDsGP9bP7qopVxSLeTWsAOtsA@mail.gmail.com>
Comments: In-reply-to Thomas Munro <thomas.munro@gmail.com>
	message dated "Sat, 18 May 2024 17:39:48 +1200"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <2682257.1716011233.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Sat, 18 May 2024 01:47:13 -0400
Message-ID: <2682258.1716011233@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2682258.1716011233%40sss.pgh.pa.us>
Precedence: bulk

Thomas Munro <thomas.munro@gmail.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.

			regards, tom lane