Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nyMxI-00011Q-Lr for pgsql-bugs@arkaria.postgresql.org; Tue, 07 Jun 2022 00:20:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nyMxH-00005R-BR for pgsql-bugs@arkaria.postgresql.org; Tue, 07 Jun 2022 00:20:19 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nyMxH-00005I-34 for pgsql-bugs@lists.postgresql.org; Tue, 07 Jun 2022 00:20:19 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nyMxC-0004Bm-0u for pgsql-bugs@lists.postgresql.org; Tue, 07 Jun 2022 00:20:18 +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 2570KB1j975367; Mon, 6 Jun 2022 20:20:11 -0400 From: Tom Lane To: Kirk Parker cc: "David G. Johnston" , PostgreSQL mailing lists Subject: Re: BUG #17511: Inconsistent permissions on some information_schema tables In-reply-to: References: <17511-ee45925b30436a87@postgresql.org> <953810.1654550302@sss.pgh.pa.us> Comments: In-reply-to Kirk Parker message dated "Mon, 06 Jun 2022 15:12:05 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <975365.1654561211.1@sss.pgh.pa.us> Date: Mon, 06 Jun 2022 20:20:11 -0400 Message-ID: <975366.1654561211@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Kirk Parker writes: > Tom Lane's answer makes sense, but I can't see where the permissions are > lacking--the user seems to have all needed rights on all the relevant > tables (and the same as the DB owner, for that matter.) [ looks closer... ] constraint_column_usage has a tighter filter than I would have guessed: \d+ information_schema.constraint_column_usage ... View definition: ... WHERE pg_has_role(x.tblowner, 'USAGE'::text); So you have to actually *be* the table owner, or at least have been GRANTed that role, in order to see entries about the table in it. This seems to match what it says in the spec, but I have to confess bafflement as to why they made this one more restrictive than either table_constraints or key_column_usage. regards, tom lane