Horton
Menu

Re: improving user.c error messages

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

View thread
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Nathan Bossart <nathandbossart@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2023-02-20T07:54:48Z
Lists: pgsql-hackers 
On 07.02.23 21:10, Nathan Bossart wrote:
>> 	ERROR:  permission denied to use replication slots
>> 	DETAIL:  You must have REPLICATION privilege.
>>
>> adding the operation to the end seems less awkward (i.e., "You must have
>> REPLICATION privilege to use replication slots.").  I don't think there's
>> any information lost by omitting the action in the DETAIL, so perhaps this
>> is just a stylistic choice.  I think I'm inclined to add the action to the
>> DETAIL whenever it doesn't make the message lengthy and awkward, and leave
>> it out otherwise.  Thoughts?
> Here is a new patch set with this change and some other light editing.

I'm concerned about the loose use of "privilege" here.  A privilege is 
something I can grant.  So if someone doesn't have the "REPLICATION 
privilege", as in the above example, I would expect to be able to do 
"GRANT REPLICATION TO someuser".  Since that is not what is happening, 
we should use some other term.  The documentation around CREATE USER 
uses the terms "attribute" and "option" (and also "privilege") for these 
things.

Similarly -- this is an existing issue but we might as well look at it 
-- in something like

     must be superuser or a role with privileges of the
     pg_write_server_files role

the phrase "a role with the privileges of that other role" seems 
ambiguous.  Doesn't it really mean you must be a member of that role?

I also feel that in sentences like

     "You must have %s privilege to create roles."

a "the" is missing.

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Improve several permission-related error messages.

  2. Integrate superuser check into has_rolreplication()

  3. Small code simplification

  4. Adjust interaction of CREATEROLE with role properties.

  5. Add new GUC reserved_connections.

  6. Rename ReservedBackends variable to SuperuserReservedConnections.

  7. Update docs and error message for superuser_reserved_connections.

  8. Add new GUC createrole_self_grant.

  9. Restrict the privileges of CREATEROLE users.

  10. Add a SET option to the GRANT command.