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 1v6F43-001VVb-Ep for pgsql-admin@arkaria.postgresql.org; Tue, 07 Oct 2025 21:17:43 +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 1v6F41-003uVY-8a for pgsql-admin@arkaria.postgresql.org; Tue, 07 Oct 2025 21:17:42 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v6F0n-003nbi-2N for pgsql-admin@lists.postgresql.org; Tue, 07 Oct 2025 21:14:21 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1v6F0l-000Yac-0j for pgsql-admin@lists.postgresql.org; Tue, 07 Oct 2025 21:14:21 +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 597LEFVI2538616; Tue, 7 Oct 2025 17:14:15 -0400 From: Tom Lane To: Ruben Laguna cc: Laurenz Albe , pgsql-admin@lists.postgresql.org Subject: Re: role to access all information_schema.*? In-reply-to: References: Comments: In-reply-to Ruben Laguna message dated "Tue, 07 Oct 2025 22:59:57 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2538614.1759871655.1@sss.pgh.pa.us> Date: Tue, 07 Oct 2025 17:14:15 -0400 Message-ID: <2538615.1759871655@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Ruben Laguna writes: > Do you know what the standard says exactly, does it outright bans using any > special means like having (pg_metadata_viewr or pg_read_information_schema, > etc). as "access privilege"? Do you think it's hopeless to propose this in > pgsql-hackers? You can propose all you want, but I doubt there will be a lot of interest in it. In the first place, the pg_read_all_data role already exists and gets the job done without any arguable violation of the standard. In the second place, we really don't take that much interest in the information_schema. It's there for pro-forma spec compliance, but it performs very poorly (not least because it has to check the spec-mandated privilege restrictions). Moreover there are significant aspects of Postgres that simply aren't represented in the information_schema because they're outside the standard. So the advice you'll generally get is what Laurenz already said, namely look directly at the PG catalogs. That being the case, and since there's a pretty decent argument that such a role would violate the SQL spec, I doubt it'll happen. regards, tom lane