Re: [EXTERNAL] Re: Windows Application Issues | PostgreSQL | REF # 48475607 - Mailing list pgsql-bugs

From Andrew Dunstan
Subject Re: [EXTERNAL] Re: Windows Application Issues | PostgreSQL | REF # 48475607
Date
Msg-id 0ba29a3c-9c1c-44c4-84a0-3405f8464075@dunslane.net
Whole thread Raw
In response to Re: [EXTERNAL] Re: Windows Application Issues | PostgreSQL | REF # 48475607  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: [EXTERNAL] Re: Windows Application Issues | PostgreSQL | REF # 48475607
List pgsql-bugs
On 2024-07-21 Su 7:54 AM, Thomas Munro wrote:
> A minor release deadline is only a couple of weeks away and
> unfortunately we still have no confirmation from a Windows user that
> this technique can be used to unbreak a database cluster that actually
> goes though that exact upgrade sequence.  So I spent today figuring
> out how to write a TAP test to try to convince myself of that in the
> abstract.  No C code change from v2.  Does the test show a useful
> enough pathway that is likely to help people in future cases at least?
>
> I learned two new things:
>
> 1.  With a remapped locale, you can log into your existing databases
> again, but CREATE DATABASE doesn't work (see test).  That must have
> been the case for the historical transitions that were hard-coded
> (Macau etc); this is no different, it's just that the mapping table is
> now user-changeable.  In other words, this just gives an administrator
> a way to log into a cluster again after such a change, but then they
> really need to update the names in catalogs, at least for any database
> that might be used as a template, to get a 100% functional system.  So
> I have added a paragraph to the documentation piece to explain that.
>
> 2.  Including the encoding suffix eg "en-US.1252" doesn't actually
> work after all (discovered by CI).  You have to use just "en-US".  (I
> guess ".UTF-8" must be a special case.)  So I have updated the
> documentation example.


I don't have a general comment, at least yet, but a couple, mostly 
stylistic, on your TAP test.


change

     if ($^O eq 'MSWin32')

to

     if ($windows_os)


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.

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.

The substance of the test looks good.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-bugs by date:

Previous
From: Thomas Munro
Date:
Subject: Re: [EXTERNAL] Re: Windows Application Issues | PostgreSQL | REF # 48475607
Next
From: Christophe Pettus
Date:
Subject: Re: BUG #18547: bemused by your unhelpful installation guides