Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sWCE8-00DlY4-Ph for pgsql-general@arkaria.postgresql.org; Tue, 23 Jul 2024 09:54:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sWCD8-00C4Jx-CI for pgsql-general@arkaria.postgresql.org; Tue, 23 Jul 2024 09:53:34 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sWCD7-00C4Jp-VW for pgsql-general@lists.postgresql.org; Tue, 23 Jul 2024 09:53:34 +0000 Received: from mail-yb1-xb2d.google.com ([2607:f8b0:4864:20::b2d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sWCD5-0012EA-54 for pgsql-general@lists.postgresql.org; Tue, 23 Jul 2024 09:53:33 +0000 Received: by mail-yb1-xb2d.google.com with SMTP id 3f1490d57ef6-e05ecb3dbf6so5131684276.0 for ; Tue, 23 Jul 2024 02:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1721728409; x=1722333209; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SAIMsf4O54zE8hhrFOIJKfwLpHb5roWcoI7BaKr0/m0=; b=f+amzOX8f5axYXsIrtmtMY+lEc4apdDdn0LMeZKd8FBBgsO8vb3tgOSBqchkeZalTA sutKYfKkmMI/xbzkntsJ5YufqICxh0q2hOX6nb+KB9+kieD3WUy0zeGmG1SA/FA3sdrt ViAuxjQ8u6OwhVs72KdhMbtutngwrUSzC5tdjvXZsFizNoLtyziulkBEU7WKSckgs3m6 4FXjCNeS5FkzyJlxTJKuo0A3mO7MX9u79YaugrkM1CSbQsq9LcJPxRvYlgiKasHJMADf L1ATcAV3cAcTDj8OgXHfGidMtCXLOjIvfBSZuvRbkT3qMAyqKOk6fMntXihxJz6dTObc D13Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721728409; x=1722333209; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SAIMsf4O54zE8hhrFOIJKfwLpHb5roWcoI7BaKr0/m0=; b=UCSwKAKrI42DD3euMQ+ExxGdC9+EIrdYTqd4dV2iDkh9+LGWVaYXMJDpG4aTJJJzUS 0+e5ZdEmwY7YYHArhbycWEMkXSRv4wPsjUiKZdpNsSIlsZfNnJzu3NmwEcoUKgtZpRMM O4dqavA62OsbBsMCDtOAFfdVJE5xeG3ZorG/GgLP6/n3cjIqGfPUHZOvzn/kvgec7OgT G917vWgwgDd7zJrN25Vco0rTHQZ/WmAmbh5fv5xhJN1s/xtfd59M4yesaLPlS6Tnr0sY 2yK25hrXxGbNj0TSjDafrZzwcGMy0bDZqOZFC5AJmgvhiWRnL/soGs0kv8AGwJeto5zD K2nw== X-Forwarded-Encrypted: i=1; AJvYcCVPi2QnwhdKDiwbZGwoRHXdOZhpdesMk3cExq1WRV2nD1uiiaHUGnOXwpqxAvaFMm8Z6VWzxWYeN8cQfCbDs+p4L+x63zxGjLGl0WvykAjWiMNN X-Gm-Message-State: AOJu0YwIVfjjJHFwnNzk5OAVL8qoJST2ujDrbMNZAbYtG2TBmamYMDfx bgTwnYlrGAKHt1GS/z/YhQ8nB8tNcMH9gdATn8XCr44WxlCs6WJ3ZQKjVpJEamZIEOauVFgf8Fj Jdf78EbKqsIJoqKRpOd+rhuxSo8VwhCBxmGUq X-Google-Smtp-Source: AGHT+IG4JEo9X+yMAz2ALMrFHFzHt2tWchljWsvVX+dYT7Q6Gp4KbdbFQ9tccbLL2TUWUCR+gGEOOPvyICoSZIdkj0s= X-Received: by 2002:a05:6902:993:b0:e08:7bf9:4d53 with SMTP id 3f1490d57ef6-e087bf9527emr12599541276.49.1721728408471; Tue, 23 Jul 2024 02:53:28 -0700 (PDT) MIME-Version: 1.0 References: <80c9b0ea-c874-40ad-a006-fb1eb37464c2@aklaver.com> <44b44ece-dce6-4b4f-b751-8787a5a071e0@aklaver.com> In-Reply-To: From: Sandeep Thakkar Date: Tue, 23 Jul 2024 15:23:12 +0530 Message-ID: Subject: Re: Windows installation problem at post-install step To: Dave Page Cc: Thomas Munro , =?UTF-8?B?RXJ0YW4gS8O8w6fDvGtvZ2x1?= , Adrian Klaver , pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000002fe848061de722ba" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000002fe848061de722ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 23, 2024 at 1:58=E2=80=AFPM Dave Page wrote: > > > On Tue, Jul 23, 2024 at 1:27=E2=80=AFAM Thomas Munro > wrote: > >> On Mon, Jul 22, 2024 at 11:51=E2=80=AFPM Sandeep Thakkar >> wrote: >> > EDB's windows installer gets the locales on the system using the >> https://github.com/EnterpriseDB/edb-installers/blob/REL-16/server/script= s/windows/getlocales/getlocales.cpp >> and then substitute some patterns ( >> https://github.com/EnterpriseDB/edb-installers/blob/REL-16/server/pgserv= er.xml.in#L2850) >> I'm not sure why we do that but that is the old code and probably @Dave >> Page may know but I'm not sure if that piece of code is responsible for >> this change in encoding in this case. >> >> Ah, so it's calling EnumSystemLocales(). Interestingly, the >> documentation for that function says: >> >> "Note For interoperability reasons, the application should prefer the >> EnumSystemLocalesEx function to EnumSystemLocales because Microsoft is >> migrating toward the use of locale names instead of locale identifiers >> for new locales. Any application that will be run only on Windows >> Vista and later should use EnumSystemLocalesEx." >> >> That seems to be talking about this exact issue, that we're supposed >> to be using "locale names". I'm a little confused about the >> terminology for the various types of names and identifiers but if you >> follow the link to a example program[1] you can see that it's talking >> about the BCP47 "en-US" kind, that we want. (That quote makes it >> sound like a new thing, but Vista came out ~17 years ago.) >> > > Vista is when they added support for BCP47, but of course, back when that > code was written we were primarily supporting older versions of Windows > still, back to Windows 2000 iirc. > > yes, that's right. In existing branches, will replacing the EnumSystemLocales() with EnumSystemLocalesEx() plus the source code path being worked upon by Thomas fix the issue? Can give it a try > >> So one idea would be that in v18, we not only change initdb.exe to >> pick a BCP47 locale name by default as I proposed in that other >> thread[2], but also in the v18 version of the EDB installer you >> consider switching that code over to EnumSystemLocalesEx(). Then we >> can start to kiss goodbye to the bad old names. People would still >> propagate them into the future with pg_upgrade I guess, and it'd be up >> to users to replace them by updating their catalogs manually. Does >> that make sense? >> > > Yes, it does (spitballing: might be nice if we could automatically update > the catalogs as well). > > -- > Dave Page > VP, Chief Architect, Database Infrastructure > EDB: https://www.enterprisedb.com > > --=20 Sandeep Thakkar --0000000000002fe848061de722ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 23, 2024 at 1:58=E2= =80=AFPM Dave Page <dave.p= age@enterprisedb.com> wrote:


On Tue, Jul 23, 2= 024 at 1:27=E2=80=AFAM Thomas Munro <thomas.munro@gmail.com> wrote:
On Mon, Jul 22, 2024 at 11:5= 1=E2=80=AFPM Sandeep Thakkar
<s= andeep.thakkar@enterprisedb.com> wrote:
> EDB's windows installer gets the locales on the system using the <= a href=3D"https://github.com/EnterpriseDB/edb-installers/blob/REL-16/server= /scripts/windows/getlocales/getlocales.cpp" rel=3D"noreferrer" target=3D"_b= lank">https://github.com/EnterpriseDB/edb-installers/blob/REL-16/server/scr= ipts/windows/getlocales/getlocales.cpp and then substitute some pattern= s (https://gi= thub.com/EnterpriseDB/edb-installers/blob/REL-16/server/pgserver.xml.in#L28= 50) I'm not sure why we do that but that is the old code and probab= ly @Dave Page=C2=A0 may know but I'm not sure if that piece of code is = responsible for this change in encoding in this case.

Ah, so it's calling EnumSystemLocales().=C2=A0 Interestingly, the
documentation for that function says:

"Note=C2=A0 For interoperability reasons, the application should prefe= r the
EnumSystemLocalesEx function to EnumSystemLocales because Microsoft is
migrating toward the use of locale names instead of locale identifiers
for new locales. Any application that will be run only on Windows
Vista and later should use EnumSystemLocalesEx."

That seems to be talking about this exact issue, that we're supposed to be using "locale names".=C2=A0 I'm a little confused about= the
terminology for the various types of names and identifiers but if you
follow the link to a example program[1] you can see that it's talking about the BCP47 "en-US" kind, that we want.=C2=A0 (That quote mak= es it
sound like a new thing, but Vista came out ~17 years ago.)
=

Vista is when they added support for BCP47, but of cour= se, back when that code was written we were primarily supporting older vers= ions of Windows still, back to Windows 2000 iirc.
=C2=A0
yes, that's right. In existing branches,=C2= =A0will replacing the=C2=A0EnumSystemLocales()
with=C2=A0EnumSystemLocalesEx() plus the source code path being worked upon by
T= homas fix the issue? Can give it a try

So one idea would be that in v18, we not only change initdb.exe to
pick a BCP47 locale name by default as I proposed in that other
thread[2], but also in the v18 version of the EDB installer you
consider switching that code over to EnumSystemLocalesEx().=C2=A0 Then we can start to kiss goodbye to the bad old names.=C2=A0 People would still propagate them into the future with pg_upgrade I guess, and it'd be up<= br> to users to replace them by updating their catalogs manually.=C2=A0 Does that make sense?

Yes, it does (spitball= ing: might be nice if we could automatically update the catalogs as well).<= /div>

-- =
Dave PageVP, Chief Architect, Database Infrastructure
EDB:=C2=A0https://www.enterprisedb.com<= /a>



--
Sandeep Thakkar


--0000000000002fe848061de722ba--