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 1o83ED-0001rw-Qk for pgsql-hackers@arkaria.postgresql.org; Sun, 03 Jul 2022 17:17:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1o83EC-0007mF-LM for pgsql-hackers@arkaria.postgresql.org; Sun, 03 Jul 2022 17:17:48 +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 1o83EC-0007m6-Ao for pgsql-hackers@lists.postgresql.org; Sun, 03 Jul 2022 17:17:48 +0000 Received: from mail-pl1-x62d.google.com ([2607:f8b0:4864:20::62d]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1o83E9-00034a-VJ for pgsql-hackers@postgresql.org; Sun, 03 Jul 2022 17:17:47 +0000 Received: by mail-pl1-x62d.google.com with SMTP id m2so6667020plx.3 for ; Sun, 03 Jul 2022 10:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=RvDHPjzpjN0v3zsCybYYgfqIJBnu/pXnsMa2To8uOFc=; b=hpS/yO5vdC6deAt1gInonDEWbO8o9Cp5wlfkiaq3u1vV34i785fGAmAjM22Z0axsw+ v2BiUw+c52wZgWiV1uwIwITCVV+sbnWfjAdI/HI6HXGfK7zhAAo68PmQOfjtbS1dnD8q W0B0Jso6zp5hIXusnWkL707d9SJDd8ynVAQOtbKhY+kxUA4cexXdAF6/MprJXnRbaLeD fqIYhM27dgD/oEWRvC/oh5mLHZCya6MIExga0CoXUNMTk0jbGuWMUM5oGOnmmlX40HGz qpQ35rTObiJrVA1P/cxyQ989Ab50bXQTrYeiPCIFNDDqo1IMeMGucKUVxKAR9rSGiEX2 AiGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=RvDHPjzpjN0v3zsCybYYgfqIJBnu/pXnsMa2To8uOFc=; b=4QNcinK1YdA/FAQxuV598KZb4j3nyAt7KJJ8p1MFOKu5HXuyIOwHmgYLIjH4ZJfaoS gYqYBfnYTL2b+CpjQ4ZQGLRLMVqhcUu0/Js9qkg2uAbCuIFzVyLlLv6fvYkoxzXILHUA DT0Zt7S9ejl+89n/2DLLk/nwtiXJ14GaZ+14k8Sm9q1suvPh6ChSI75GIFpzQLwCl/Bq zI29BkL/qQ+wtoAwpEB1akbmY73iy1vWq0X9GRvN+AWF411pizk7MhVMmjn6YeGDDEY5 H+ATuBpO/KEElVhmSXxskC3uRFY7H9jkMzP0UbpqKPWCNAi4KCtOR/7cZI6IVDDFqdiP Yx4w== X-Gm-Message-State: AJIora/ASqjwZIejQyPX2VEDSFOVsCc+YUeAsVerTOSSteaoO750lp6A nnxQYk0ld2K3vDtJ9mhV5JM= X-Google-Smtp-Source: AGRyM1vKa8zrErQGqTflQCfPyq7M63qhpvvjodjS8S9kmNplKzKQbBU0DvgZxjaP/vyBzdM3C6/tKA== X-Received: by 2002:a17:90b:4f45:b0:1ed:3fe:e54 with SMTP id pj5-20020a17090b4f4500b001ed03fe0e54mr33443275pjb.32.1656868664829; Sun, 03 Jul 2022 10:17:44 -0700 (PDT) Received: from nathanxps13 ([50.54.155.70]) by smtp.gmail.com with ESMTPSA id f33-20020a17090a702400b001e667f932cdsm3630644pjk.53.2022.07.03.10.17.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 Jul 2022 10:17:44 -0700 (PDT) Date: Sun, 3 Jul 2022 10:17:42 -0700 From: Nathan Bossart To: Robert Haas Cc: Joe Conway , Tom Lane , "Bossart, Nathan" , Stephen Frost , PostgreSQL-development Subject: Re: replacing role-level NOINHERIT with a grant-level option Message-ID: <20220703171742.GB1048244@nathanxps13> References: <20220701025830.GA369935@nathanxps13> <12e2f0cb-08ff-c65f-d31e-76cea1af70ec@joeconway.com> <442d7887-645d-0e31-e971-7a8dc8952d2f@joeconway.com> <20220701211225.GA418166@nathanxps13> <20220702221635.GB1044460@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sat, Jul 02, 2022 at 11:04:28PM -0400, Robert Haas wrote: > On Sat, Jul 2, 2022 at 6:16 PM Nathan Bossart wrote: >> I was thinking that when DEFAULT was removed, pg_dump would just need to >> generate WITH INHERIT TRUE/FALSE based on the value of rolinherit for older >> versions. Using the role-level property as the default for future grants >> seems a viable strategy, although it would break backward compatibility. >> For example, if I create a NOINHERIT role, grant a bunch of roles to it, >> and then change it to INHERIT, the role won't begin inheriting the >> privileges of the roles it is a member of. Right now, it does. > > I think the idea you propose here is interesting, because I think it > proves that committing v2 or something like it doesn't really lock us > into the role-level property any more than we already are, which at > least makes me feel slightly less bad about that option. However, if > there's implacable opposition to any compatibility break at any point, > then maybe this plan would never actually be implemented in practice. > And if there's not, maybe we can be bolder now. If by "bolder" you mean "mark [NO]INHERIT as deprecated-and-to-be-removed and begin emitting WARNINGs when it and WITH INHERIT DEFAULT are used," I think it's worth consideration. I suspect it will be hard to sell removing [NO]INHERIT in v16 because it would introduce a compatibility break without giving users much time to migrate. I could be wrong, though. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com