createuser doesn't tell default settings for some options - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject createuser doesn't tell default settings for some options
Date
Msg-id 20220810.151243.1073197628358749087.horikyota.ntt@gmail.com
Whole thread Raw
Responses Re: createuser doesn't tell default settings for some options
List pgsql-hackers
(I suppose this is a pg15 issue)

createuser --help shows the following help text.

>  --bypassrls               role can bypass row-level security (RLS) policy
>  --no-bypassrls            role cannot bypass row-level security (RLS) policy
>  --replication             role can initiate replication
>  --no-replication          role cannot initiate replication

For other options the text tells which one is the default, which I
think the two options also should have the same.

>  -r, --createrole          role can create new roles
>  -R, --no-createrole       role cannot create roles (default)

In correspondence, it seems to me that the command should explicitly
place the default value (of the command's own) in generated SQL
command even if the corresponding command line options are omitted, as
createrole and so do. (attached first)

The interacitive mode doesn't cover all options, but I'm not sure what
we should do to the mode since I don't have a clear idea of how the
mode is used.  In the attached only --bypassrls is arbirarily added.
The remaining options omitted in the interactive mode are: password,
valid-until, role, member and replication. (attached second)

The ternary options are checked against decimal 0, but it should use
TRI_DEFAULT instead. (attached third)

I tempted to check no ternary options remains set to TRY_DEFAULT
before generating SQL command, but I didn't that in the attached.

What do you think about this?

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock
Next
From: David Rowley
Date:
Subject: Re: Reducing the chunk header sizes on all memory context types