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 1smka3-007zTb-5I for pgsql-bugs@arkaria.postgresql.org; Sat, 07 Sep 2024 01:49:39 +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 1smka1-0086u8-Gu for pgsql-bugs@arkaria.postgresql.org; Sat, 07 Sep 2024 01:49:37 +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 1smka1-0086u0-83 for pgsql-bugs@lists.postgresql.org; Sat, 07 Sep 2024 01:49:37 +0000 Received: from smtp109.iad3a.emailsrvr.com ([173.203.187.109]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1smkZu-000XLJ-7r for pgsql-bugs@lists.postgresql.org; Sat, 07 Sep 2024 01:49:35 +0000 X-Auth-ID: xof@thebuild.com Received: by smtp30.relay.iad3a.emailsrvr.com (Authenticated sender: xof-AT-thebuild.com) with ESMTPSA id 95695542A; Fri, 6 Sep 2024 21:49:28 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications From: Christophe Pettus In-Reply-To: Date: Fri, 6 Sep 2024 18:48:57 -0700 Cc: PostgreSQL Bug List Content-Transfer-Encoding: quoted-printable Message-Id: <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> To: Basha X-Mailer: Apple Mail (2.3774.600.62) X-Classification-ID: 9a43cd61-af8c-4b72-9bc9-7275e169d722-1-1 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On Sep 6, 2024, at 18:40, Basha wrote: >=20 > I mean the case where, changes to system tables made. pg_dump to do = granular control over it.=20 > Which means the pg_dump will work on the dev environments too, when = there is a change to the system tables. Anything's possible, but just speaking for myself, that doesn't seem = like an attractive area of development. I don't think it's possible to = guarantee that pg_dump (or anything else) will always work with = arbitrary system catalog modifications. 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 = imaginable, 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 see all databases" wouldn't be a great way forward.=