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

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: "Haifang Wang (Centific Technologies Inc)" <v-haiwang(at)microsoft(dot)com>, Rahul Pandey <pandeyrah(at)microsoft(dot)com>, Vishwa Deepak <Vishwa(dot)Deepak(at)microsoft(dot)com>, Shawn Steele <Shawn(dot)Steele(at)microsoft(dot)com>, Amy Wishnousky <amyw(at)microsoft(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Shweta Gulati <gulatishweta(at)microsoft(dot)com>, Ashish Nawal <nawalashish(at)microsoft(dot)com>
Subject: Re: [EXTERNAL] Re: Windows Application Issues | PostgreSQL | REF # 48475607
Date: 2024-07-21 22:00:28
Message-ID: CA+hUKGJasTBQ1THqDeeVdeRSFao3+T1LGnwJfqmT4sR-WmTebQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Mon, Jul 22, 2024 at 1:28 AM Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> change
>
> if ($^O eq 'MSWin32')
>
> to
>
> if ($windows_os)

Done.

> Also your use of "is()" is unidiomatic. The expected value should come
> after the received value, not before. While your use won't change the
> success or failure of the result, the message on failure will be at best
> confusing. (I ran into this the other day, so it's fresh in my memory).
> See Test::More documentation.

Fixed.

> Using all upper case for variables is not our usual perl style (or
> anybody else's that I am aware of). Mostly we just use lower case with
> underscores. If you use the "constant" module upper case letters are
> usually used, but then the things defined are bare words, and come with
> some caveats, and I don't think you want to use it here.

Fixed.

> The substance of the test looks good.

Thanks for looking!

One new-to-me fact from the -general mailing list this morning[1] is
that the EDB installer is explicitly feeding these unstable locale
names into the world's database clusters, so that's something that's
beyond the power of us upstream PostgreSQL hackers to fix even if we
pulled the trigger on the initdb BCP47-by-default patch[2]. Something
for someone at EDB to look into?

[1] https://www.postgresql.org/message-id/flat/CA%2BhUKGJA4pGEeZtfUUEuQmNNO7x16wZ%2BRWOeXP%2Btq3Hf4iu8oQ%40mail.gmail.com#6426ff9fd44fbcd9a7f343a3f94ae364
[2] https://www.postgresql.org/message-id/flat/CA+hUKGJ=XThErgAQRoqfCy1bKPxXVuF0=2zDbB+SxDs59pv7Fw(at)mail(dot)gmail(dot)com

Attachment Content-Type Size
v4-0001-Make-win32locale.c-s-kludge-table-dynamic.patch text/x-patch 26.3 KB
v4-0002-ci-Enable-DEBUG_SETLOCALE_MAP-on-FreeBSD-task.patch text/x-patch 1.5 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Jason ChenTJ (CN) 2024-07-22 02:51:35 回复: [External]Re: BUG #18540: Does PG16 standby database support function pg_replication_origin_advance?
Previous Message David G. Johnston 2024-07-21 19:39:43 Re: BUG #18547: bemused by your unhelpful installation guides