Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.2\))
Subject: Re: pgsql: Clean up role created in new subscription test.
From: Daniel Gustafsson <daniel@yesql.se>
In-Reply-To: <267900.1680201870@sss.pgh.pa.us>
Date: Thu, 30 Mar 2023 21:19:17 +0200
Cc: Robert Haas <robertmhaas@gmail.com>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <99112997-6732-42C7-989B-06406C911FE2@yesql.se>
References: <E1phvk7-000VAH-7k@gemulon.postgresql.org>
 <CA+TgmoZ+K2OU0Ojs8_4SgqPWJJq7e0XiLd-uJGZ11R_WKF1URQ@mail.gmail.com>
 <267900.1680201870@sss.pgh.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/99112997-6732-42C7-989B-06406C911FE2%40yesql.se>
Precedence: bulk

> On 30 Mar 2023, at 20:44, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Maybe it'd be close enough to expect there to be no roles named
> "regress_xxx".  In combination with
> -DENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS, that would prevent us
> from accidentally leaving stuff behind, and we could hope that it =
doesn't
> cause false failures in real installations.

Would that check be always on or only when pg_regress is compiled with
-DENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS?

> Another idea could be for pg_regress to enforce that "select count(*)
> from pg_roles" gives the same answer before and after the test run.

That wouldn't prevent the contents of pg_roles to have changed though, =
so there
is a (slim) false positive risk with that no?

--
Daniel Gustafsson