Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Julien Rouhaud <rjuju123(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
Date: 2022-02-14 08:01:05
Message-ID: YgoMQQgZrQihu/+C@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2022-02-14 08:14:28 Re: Assertion failure in WaitForWALToBecomeAvailable state machine
Previous Message Michael Paquier 2022-02-14 06:40:23 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set