Re: Add --{no-,}bypassrls flags to createuser
Kyotaro Horiguchi <horikyota.ntt@gmail.com>
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: robertmhaas@gmail.com
Cc: Shinya11.Kato@oss.nttdata.com, daniel@yesql.se, michael@paquier.xyz,
pgsql-hackers@postgresql.org
Date: 2022-04-19T01:50:12Z
Lists: pgsql-hackers
Thanks!
At Mon, 18 Apr 2022 09:59:48 -0400, Robert Haas <robertmhaas@gmail.com> wrote in
> On Fri, Apr 15, 2022 at 2:33 AM Kyotaro Horiguchi
> <horikyota.ntt@gmail.com> wrote:
> > > 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.
>
> 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.
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.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix output of createuser --help with --valid-until
- 4ca998595788 16.0 landed
-
createuser: Add support for more clause types through new options
- 08951a7c93cf 16.0 landed
-
createuser: Cleanup and fix internal option ordering
- 50e4c280f066 16.0 landed
-
Add REPLICATION privilege for ROLEs
- 9b8aff8c192e 9.1.0 cited