Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sml1Q-0082Pc-ER for pgsql-bugs@arkaria.postgresql.org; Sat, 07 Sep 2024 02:17:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sml1O-008X13-SZ for pgsql-bugs@arkaria.postgresql.org; Sat, 07 Sep 2024 02:17:55 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sml1O-008X0u-Jt for pgsql-bugs@lists.postgresql.org; Sat, 07 Sep 2024 02:17:54 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sml1M-000XV5-UI for pgsql-bugs@lists.postgresql.org; Sat, 07 Sep 2024 02:17:54 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 4872Hpov2410943; Fri, 6 Sep 2024 22:17:51 -0400 From: Tom Lane To: Christophe Pettus cc: Basha , PostgreSQL Bug List Subject: Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications In-reply-to: <01CF2C94-D153-4687-B2EF-EF4B4B1890DF@thebuild.com> References: <18604-04d64b68e981ced6@postgresql.org> <3B462E2E-88B6-43B9-943F-90E883D33357@thebuild.com> <183A6734-06B2-48E9-A5C9-235EF87B0DFB@thebuild.com> <6860E1BC-DA5A-4576-9FB6-35ED31E6F017@thebuild.com> <73AD2F56-1009-49C7-8752-39C45325A9BB@thebuild.com> <01CF2C94-D153-4687-B2EF-EF4B4B1890DF@thebuild.com> Comments: In-reply-to Christophe Pettus message dated "Fri, 06 Sep 2024 18:48:57 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2410941.1725675471.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Fri, 06 Sep 2024 22:17:51 -0400 Message-ID: <2410942.1725675471@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Christophe Pettus writes: > The real problem you're trying to solve that that users can discover the= existence of databases that they can't connect to. That's much more imag= inable, although I'm not sure how practical it would be. At minimum, the = default behavior would have to be the same as it is now (or lots of things= that work now would break), so introducing a new role privilege of "can s= ee all databases" wouldn't be a great way forward. Even more to the point: that doesn't really seem like a problem worth putting development and ongoing maintenance effort into. What does it matter if someone can see that database XYZ exists, as long as they can't connect to it? regards, tom lane