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 1p39Fw-0004Te-Lv for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Dec 2022 05:15:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1p39Fu-0006AV-Ih for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Dec 2022 05:15:34 +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 1p39Fu-0006AM-4X for pgsql-hackers@lists.postgresql.org; Thu, 08 Dec 2022 05:15:34 +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 1p39Fn-0001NV-K3 for pgsql-hackers@postgresql.org; Thu, 08 Dec 2022 05:15:32 +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 2B85FNjR045225; Thu, 8 Dec 2022 00:15:23 -0500 From: Tom Lane To: Nathan Bossart cc: Isaac Morland , Justin Pryzby , Pavel Luzanov , pgsql-hackers@postgresql.org Subject: Re: add \dpS to psql In-reply-to: <20221208050754.GA221222@nathanxps13> References: <20221206193606.GB3078082@nathanxps13> <661148f4-c7f1-dec1-2bc8-29f3bd58e242@postgrespro.ru> <20221208023929.GB27893@telsasoft.com> <20221208041900.GB216874@nathanxps13> <39743.1670473532@sss.pgh.pa.us> <20221208050754.GA221222@nathanxps13> Comments: In-reply-to Nathan Bossart message dated "Wed, 07 Dec 2022 21:07:54 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <45223.1670476523.1@sss.pgh.pa.us> Date: Thu, 08 Dec 2022 00:15:23 -0500 Message-ID: <45224.1670476523@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Nathan Bossart writes: > On Wed, Dec 07, 2022 at 11:48:20PM -0500, Isaac Morland wrote: >> My previous analysis >> shows that there is no vast hidden demand for new privilege bits. If we >> implement MAINTAIN to control access to VACUUM, ANALYZE, REFRESH, CLUSTER, >> and REINDEX, we will cover everything that I can find that has seriously >> discussed on this list, and still leave 3 unused bits for future expansion. > If we added CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX as individual > privilege bits, we'd still have 13 remaining for future use. I think the appropriate question is not "have we still got bits left?". It should be more like "under what plausible scenario would it be useful to grant somebody CLUSTER but not VACUUM privileges on a table?". I'm really thinking that MAINTAIN is the right level of granularity here. Or maybe it's worth segregating exclusive-lock from not-exclusive-lock maintenance. But I really fail to see how it's useful to distinguish CLUSTER from REINDEX, say. regards, tom lane