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 1p3KUJ-0005aa-U7 for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Dec 2022 17:15:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1p3KUI-0006zS-EX for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Dec 2022 17:15:10 +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 1p3KUI-0006zI-2B for pgsql-hackers@lists.postgresql.org; Thu, 08 Dec 2022 17:15:10 +0000 Received: from mail-pj1-x1034.google.com ([2607:f8b0:4864:20::1034]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1p3KUF-0003QG-C9 for pgsql-hackers@postgresql.org; Thu, 08 Dec 2022 17:15:09 +0000 Received: by mail-pj1-x1034.google.com with SMTP id b13-20020a17090a5a0d00b0021906102d05so2192332pjd.5 for ; Thu, 08 Dec 2022 09:15:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=7Y3v68YZ7hvb0U3IxgLqqt1OcbniEXlwfNCznxYlyWo=; b=nNsfznrM4+WdhGSdoOVRQnrae+Ki2d0r0nACHn74CF7Aru6p8fjra4mXZmcpTQJ7BD Ox1uYkN9xsDLu67rax0MJtfz7M7hLF72BD5/NO/YoLA5oMd9eTr+n1RVH/Nye6UhNU1h mVfnEc0L85ps/9XFMiA3wKe2tLYgNZZcLrsnvBL670E/ARiTYQ7LeotfFkaVIoijiiYa bpj8jGfRgiJZeH1WnYxihiaMYmyGgdyqsmUZnvNUV2CnguI8dv8Pmfm3VCquMHLp4zM4 lhubzLqqmpv2z+lN5gfcbJjFmaOBnssHmE0Hh5Wf+bqIYAOtr71qTHY1Re1lyu0YCq7o 7MVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7Y3v68YZ7hvb0U3IxgLqqt1OcbniEXlwfNCznxYlyWo=; b=64FersFPSqKRx5e2z18XD8ytqBS6dVWFnw+GQW0l3eDhR2KjulO8+TmJnnut+vQfJe YymtQPtjE6LmBTqLLB7IItSAGoA3etYL2UAsdUtwsSrGT7C5REa2olljMlNx+iGKeLrH 9rmLiOUAxfbT8SnDKWVCgeIGntQmPGQfXXtDDRO7+8apd5aS9B6TS2JdBm/3onDjWrBx 1Cgr+aX/LqE5titGtcV2f99krs6za4pxpDSlXuS1pXHnG3uHnnG4VsSWUGiLu5AGZJzH zt0i4D1FBOh8yKxGzjP8CheykvmviYKUhO3Y7y9Y3xit3thK8TSySKwNLABGcKC2WZp4 2mlA== X-Gm-Message-State: ANoB5plgcADOC2oSD8kp5X8yTfPY11fYq6ht904JxWhzqValY78mKgAj 4uFhHyn+9RgbteySSLraC9o= X-Google-Smtp-Source: AA0mqf58LH7JqZnFYpvcGIPiu0fwjmbxi3o3OcsKThUMvY6AGUXC7DbogmGX3PCtmXc/fSVd0M/EnQ== X-Received: by 2002:a17:902:7689:b0:189:b6cf:850d with SMTP id m9-20020a170902768900b00189b6cf850dmr30604908pll.30.1670519705510; Thu, 08 Dec 2022 09:15:05 -0800 (PST) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id q2-20020a635c02000000b004768b74f208sm13304546pgb.4.2022.12.08.09.15.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Dec 2022 09:15:04 -0800 (PST) Date: Thu, 8 Dec 2022 09:15:03 -0800 From: Nathan Bossart To: Tom Lane Cc: Isaac Morland , Justin Pryzby , Pavel Luzanov , pgsql-hackers@postgresql.org Subject: Re: add \dpS to psql Message-ID: <20221208171503.GA2113@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> <45224.1670476523@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <45224.1670476523@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Dec 08, 2022 at 12:15:23AM -0500, Tom Lane wrote: > 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. The main idea behind this work is breaking out privileges into more granular pieces. If I want to create a role that only runs VACUUM on some tables on the weekend, why ѕhould I have to also give it the ability to ANALYZE, REFRESH, CLUSTER, and REINDEX? IMHO we should really let the user decide what set of privileges makes sense for their use-case. I'm unsure the grouping all these privileges together serves much purpose besides preserving ACL bits. The other reason I'm hesitant to group the privileges together is because I suspect it will be difficult to reach agreement on how to do so, as evidenced by past discussion [0]. That being said, I'm open to it if we find a way that folks are happy with. For example, separating exclusive-lock and non-exclusive-lock maintenance actions seems like a reasonable idea (which perhaps is an argument for moving VACUUM FULL out of the VACUUM privilege). [0] https://postgr.es/m/67a1d667e8ec228b5e07f232184c80348c5d93f4.camel%40j-davis.com -- Nathan Bossart Amazon Web Services: https://aws.amazon.com