Subject: Re: Add --{no-,}bypassrls flags to createuser

From: Kyotaro Horiguchi <[email-masked]>
Date: Fri, 15 Apr 2022 15:33:41 +0900 (JST)

At Fri, 15 Apr 2022 14:55:48 +0900, Shinya Kato <[email-masked]> wrote in 
> I understand. For backward compatibility, I left the ROLE clause
> option as it is and changed the IN ROLE clause option to --membership
> option.

Thanks!

-	printf(_("  -g, --role=ROLE           new role will be a member of this role\n"));
+	printf(_("  -g, --role=ROLE        new role will be a member of this role\n"));

This looks lik an unexpected change.  We shoudl preserve it, but *I*
think that we can add a synonym of the old --role for
understandability/memorability.  (By the way "-g" looks like coming
from "group", which looks somewhat strange..)

> printf(_("  -b, --belongs-to=ROLE     new role will be a member of this role\n"));

+	printf(_("  -m, --membership=ROLE     this role will be a member of new role\n"));

membership sounds somewhat obscure, it seems *to me* members is clearer

> printf(_("  -m, --member=ROLE        new role will be a member of this role\n"));

I'd like to hear others' opinions.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

---

From: Robert Haas <[email-masked]>
Date: Mon, 18 Apr 2022 09:59:48 -0400

> I'd like to hear others' opinions.

I think that we need to preserve consistency with the SQL syntax as
much as possible -- and neither MEMBER nor MEMBERSHIP nor BELONGS_TO
appear in that syntax. A lot of the terminology in this area seems
poorly chosen and confusing to me, but having two ways to refer to
something probably won't be an improvement even if the second name is
better-chosen than the first one.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

---

From: Kyotaro Horiguchi <[email-masked]>
Date: Tue, 19 Apr 2022 10:50:12 +0900 (JST)

Thanks!

At Mon, 18 Apr 2022 09:59:48 -0400, Robert Haas <[email-masked]> wrote in 
> better-chosen than the first one.

Hmm.. So, "-r/--role" and "-m/--member(ship)" is the (least worse) way
to go?  Or we can give up adding -m for the reason of being hard to
name it..

regards.

---

From: Robert Haas <[email-masked]>
Date: Tue, 19 Apr 2022 12:13:51 -0400

> to go?  Or we can give up adding -m for the reason of being hard to

Hmm, yeah, I hadn't quite realized what the problem was when I wrote
that. I honestly don't know what to do about that. Renaming the
existing option is not great, but having the syntax diverge between
SQL and CLI is not great either. Giving up is also not great. Not sure
what is best.

---

From: Kyotaro Horiguchi <[email-masked]>
Date: Wed, 20 Apr 2022 17:04:21 +0900 (JST)

At Tue, 19 Apr 2022 12:13:51 -0400, Robert Haas <[email-masked]> wrote in 
> SQL and CLI is not great either. Giving up is also not great. Not sure

Exactly..  So I'm stuckX(

regards.

---

From: Michael Paquier <[email-masked]>
Date: Thu, 21 Apr 2022 13:29:57 +0900

> SQL and CLI is not great either. Giving up is also not great. Not sure

Changing one existing option to mean something entirely different
should be avoided, as this could lead to silent breakages.  As the
origin of the problem is that the option --role means "IN ROLE" in the
SQL grammar, we could keep around --role for compatibility while
marking it deprecated, and add two new options whose names would be
more consistent with each other.  One choice could be --role-name and
--in-role-name, where --in-role-name maps to the older --role, just to
give an idea.
--
Michael

---

From: Robert Haas <[email-masked]>
Date: Thu, 21 Apr 2022 15:51:05 -0400

> --in-role-name, where --in-role-name maps to the older --role, just to

I don't think that having both --role and --role-name, doing different
things, is going to be clear at all.

---

From: "David G. Johnston" <[email-masked]>
Date: Thu, 21 Apr 2022 13:21:57 -0700

> things, is going to be clear at all.
-g/--role   or maybe/additionally (--in-role)?
-m/--role-to or maybe/additionally (--to-role)?

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.

David J.