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 1nYxJt-0008FG-Fp for pgsql-hackers@arkaria.postgresql.org; Mon, 28 Mar 2022 21:54:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nYxJs-0001Mh-9o for pgsql-hackers@arkaria.postgresql.org; Mon, 28 Mar 2022 21:54:36 +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 1nYxJr-0001MX-Rz for pgsql-hackers@lists.postgresql.org; Mon, 28 Mar 2022 21:54:35 +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 1nYxJp-00062S-Jr for pgsql-hackers@postgresql.org; Mon, 28 Mar 2022 21:54:34 +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 22SLsSD01031400; Mon, 28 Mar 2022 17:54:28 -0400 From: Tom Lane To: Mark Dilger cc: Joshua Brindle , Andrew Dunstan , Peter Eisentraut , Robert Haas , Jeff Davis , PostgreSQL-development , Joe Conway Subject: Re: Granting SET and ALTER SYSTE privileges for GUCs In-reply-to: <2AED7293-AB99-47CF-B3CA-C090108A8250@enterprisedb.com> References: <3D691E20-C1D5-4B80-8BA5-6BEB63AF3029@enterprisedb.com> <2D6C1081-DB7D-4260-8987-5B4912E95917@enterprisedb.com> <1A6DA47B-2D5F-427E-AD72-1D8BD23BF94C@enterprisedb.com> <79685.1646604824@sss.pgh.pa.us> <83814.1646607430@sss.pgh.pa.us> <78889A65-CA7A-4015-866D-33460967071D@enterprisedb.com> <92485.1646609263@sss.pgh.pa.us> <43857434-3f9b-3! 66f-0401-7aea558827e1@dunslane.net> <664799.1647456444@sss.pgh.pa.us> <771410.1647528423@sss.pgh.pa.us> <9b37fa41-a068-81! ! ! 66-78c3-4503a867de07@dunslane.net> <895087.1648494675@sss.pgh.pa.us> <18A291A8-362E-4AB1-833D-66410751E401@enterprisedb.com> <1011909.1648502174@sss.pgh.pa.us> <2AED7293-AB99-47CF-B3CA-C090108A8250@enterprisedb.com> Comments: In-reply-to Mark Dilger message dated "Mon, 28 Mar 2022 14:42:46 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1031398.1648504468.1@sss.pgh.pa.us> Date: Mon, 28 Mar 2022 17:54:28 -0400 Message-ID: <1031399.1648504468@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Mark Dilger writes: >> On Mar 28, 2022, at 2:16 PM, Tom Lane wrote: >> I just came across something odd in v12 that is still there in v13: >> ExecGrant_Parameter uses InvokeObjectPostAlterHook not >> InvokeObjectPostAlterHookArgStr. This seems pretty inconsistent. >> Is there a good argument for it? > For SET and ALTER SYSTEM, the target of the action may not have an entry > in pg_parameter_acl, nor an assigned Oid anywhere, so the only > consistent way to pass the argument to the hook is by name. For > GRANT/REVOKE, the parameter must have an Oid, at least by the time the > hook gets called. Yeah, I know it's *possible* to make this work. The question is why is it good to do it like this rather than to use the string API, now that we have the latter. AFAICS this way just guarantees that the hook must do a catalog lookup in order to figure out what you're talking about. The core point here is that the actual identity of a GUC is its name. Any OID that may exist in pg_parameter_acl is just a nonce alias that means nothing to anybody. Anyone who's trying to, say, enforce that Joe Blow can't change shared_buffers is going to need to see the GUC name. (I am, btw, busy doing a lot of renaming in the patch to try to clarify that these OIDs are not identifiers for GUCs; imagining that they are just risks confusion.) regards, tom lane