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 1nj5Bc-0003kd-TW for pgsql-hackers@arkaria.postgresql.org; Mon, 25 Apr 2022 20:19:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nj5Bb-000584-8t for pgsql-hackers@arkaria.postgresql.org; Mon, 25 Apr 2022 20:19:55 +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 1nj5Ba-00057B-VA for pgsql-hackers@lists.postgresql.org; Mon, 25 Apr 2022 20:19:54 +0000 Received: from mail-pf1-x436.google.com ([2607:f8b0:4864:20::436]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nj5BY-0003sX-9b for pgsql-hackers@postgresql.org; Mon, 25 Apr 2022 20:19:54 +0000 Received: by mail-pf1-x436.google.com with SMTP id y14so15107808pfe.10 for ; Mon, 25 Apr 2022 13:19:52 -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=l7ajGDozXcudQsg9EUvpD5eqKhLxhwsYHUCY/xNuzAo=; b=DH51vhrfLLyku+v5I88D7PXK9AoDRExqjIcBo4Ebb8zkLBxXf9lvTt6FFLgWdHszlp MCCz4Rtd/5ufutpKeRIjphX2zPyX8NFhsgxkb1nJgF2EZoVp18NBb98bjclFrC5SErJd 1Ysp1oBdZIE2J+6WgwyFneCmC9B31XCbkf+Tb5MbQZCsULkOhCPvagT1EUXZXmGbcbWE 2cCTTPHSnjy5IOkZOq3l9xdnO76n9QpqUjqXCvpBapNYOK/tsyo8L9STIykdb/jW7kRq WTsUwtkjxdGb+2IYrm1cL3+we4lBd5blO89z1Y1myGw/Il3aXIBe+XDLDcBJXr5Dur2B gOSg== 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=l7ajGDozXcudQsg9EUvpD5eqKhLxhwsYHUCY/xNuzAo=; b=NjVe3EkaQHhUjUMkkXpjX7XGWQ6aWvQqx3/3oAivLMNpTMEzI22zAE9anKymm5igDc cSeqNkucDnmLgbvZD58SuEFgBxV//5fMdbsv8dMz2wqNQLaMGD+1nIPDZU5tjYxQgRN+ qwXziTzYl4P7VLRNI9OObnu4NY1a9T5AX/HUYpP2XUuohP67cXM15HmJEMif9H3GGGf2 ZWW9wvdoS/SeglDFiZ7rkQoMVymDBgydkt/bLa4szvKnWajB4pZ2SKdQPb/G/YsL4iZc s7WHs3B+gKxlnik/HSo9nTC4D6HDm5WK3copLTzJiNjmmAOtzdQ9dlSnWWQpI66QnHVc 2KqQ== X-Gm-Message-State: AOAM53013hy0kUm+uV7P2Ie9rS25VI2uOdG2aKyWyDr1uq7BnvWvg9aG CCR4oQ5zA93qq84YEaxefpnrqzg9F+s= X-Google-Smtp-Source: ABdhPJypy+/I/In2lbIXbSh5f59gt+Ln+NWNDA5FDzmK+iAeBRaOtovkEVK6obYT7pZKYwfJylB1lA== X-Received: by 2002:a05:6a00:1392:b0:50a:7d0e:7e0b with SMTP id t18-20020a056a00139200b0050a7d0e7e0bmr20618949pfg.85.1650917990504; Mon, 25 Apr 2022 13:19:50 -0700 (PDT) Received: from nathanxps13 ([50.54.155.70]) by smtp.gmail.com with ESMTPSA id y2-20020a056a00190200b004fa865d1fd3sm12829768pfi.86.2022.04.25.13.19.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Apr 2022 13:19:49 -0700 (PDT) Date: Mon, 25 Apr 2022 13:19:47 -0700 From: Nathan Bossart To: "David G. Johnston" Cc: Robert Haas , Michael Paquier , Kyotaro Horiguchi , Shinya Kato , Daniel Gustafsson , "pgsql-hackers@postgresql.org" Subject: Re: Add --{no-,}bypassrls flags to createuser Message-ID: <20220425201947.GA2935432@nathanxps13> References: <850d0579cdad54a37fd777d6b11421ec@oss.nttdata.com> <20220415.153341.594036939490942414.horikyota.ntt@gmail.com> <20220419.105012.1677795152077894444.horikyota.ntt@gmail.com> 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 Thu, Apr 21, 2022 at 01:21:57PM -0700, David G. Johnston wrote: > I'm ok with -m/--member as well (like with --role only one role can be > specified per switch instance so member, not membership, the later meaning, > at least for me, the collective). > > That -m doesn't match --role-to is no worse than -g not matching --role, a > short option seems worthwhile, and the -m (membership) mnemonic should be > simple to pick-up. > > I don't see the addition of "-name" to the option name being beneficial. > > Yes, the standard doesn't use the "TO" prefix for "ROLE" - but taking that > liberty for consistency here is very appealing and there isn't another SQL > clause that it would be confused with. +1 for "member". It might not be perfect, but IMO it's the clearest option. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com