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 1nZaWH-0007rJ-EU for pgsql-hackers@arkaria.postgresql.org; Wed, 30 Mar 2022 15:46:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nZaWG-0004ji-Aj for pgsql-hackers@arkaria.postgresql.org; Wed, 30 Mar 2022 15:46:00 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nZaWG-0004jZ-1Y for pgsql-hackers@lists.postgresql.org; Wed, 30 Mar 2022 15:46:00 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nZaWD-0002Jl-PT for pgsql-hackers@postgresql.org; Wed, 30 Mar 2022 15:45:59 +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 22UFjrIb223666; Wed, 30 Mar 2022 11:45:53 -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: <4CE7A2D7-56C0-4DC8-A0BD-EFC1351B8D01@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> <664799.1647456444@sss.pgh.pa.us> <771410.1647528423@sss.pgh.pa.us> <895087.1648494675@sss.pgh.pa.us> <18A291A8-362E-4AB1-833D-66410751E401@e! ! nterprisedb.com> <1011909.1648502174@sss.pgh.pa.us> <2AED7293-AB99-47CF-B3CA-C090108A8250@enterprisedb.com> <1031399.1648504468@sss.pgh.pa.us> <1034902.1648506662@sss.pgh.pa.us> <212076.1648646781@sss.pgh.pa.us> <4CE7A2D7-56C0-4DC8-A0BD-EFC1351B8D01@enterprisedb.com> Comments: In-reply-to Mark Dilger message dated "Wed, 30 Mar 2022 07:45:36 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <223664.1648655153.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Mar 2022 11:45:53 -0400 Message-ID: <223665.1648655153@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Mark Dilger writes: > Your proposal to just punt on supporting revocation of set on userset fr= om public seems fine. We could revisit that in the next development cycle= if anyone really wants to defend it. In particular, I don't see that com= mitting this feature without that part would create any additional backwar= d compatibility problems when implementing that later. Yeah. Also, as you noted, we could mark some individual built-in variables as SUSET and add a default GRANT. I don't want to do that with a blunderbuss, but perhaps there's an argument to do it for specific cases (search_path comes to mind, though the performance cost could be significant, since I think setting that in function SET clauses is common). For now, though, saying that you can't restrict SET for USERSET variables seems fine --- there's certainly no loss of capability compared to where we stand today. I'd prefer to get the feature committed in that form and then look at whether we want to tighten things around the margins. regards, tom lane