Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
Date
Msg-id YgoMQQgZrQihu/+C@paquier.xyz
Whole thread Raw
In response to Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Sat, Feb 12, 2022 at 08:12:42PM -0800, Andres Freund wrote:
> It also doesn't handle @ correctly. Makes sense to fix. Should probably use
> the same logic that libpq, psql, ... use?
>
>             if (is_unixsock_path(ch->host))
>                 ch->type = CHT_UNIX_SOCKET;
>
> that'd basically be the same amount of code. And easier to understand.

So, I am catching up with some parts of this thread, and I have
managed to miss is_unixsock_path().  Except if I am missing something
(now it is close to the end of the day here), a minimal change would
be something like that as we'd still want to allow the use of
localhost and others:
    if (value && strlen(value) > 0 &&
    /* check for 'local' host values */
        (strcmp(value, "localhost") != 0 && strcmp(value, "127.0.0.1") != 0 &&
-        strcmp(value, "::1") != 0 && value[0] != '/'))
+        strcmp(value, "::1") != 0 && !is_unixsock_path(value)))

Or perhaps we should restrict more the use of localhost values for
non-WIN32?  Opinions?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Assertion failure in WaitForWALToBecomeAvailable state machine