Re: doc - improve description of default privileges - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: doc - improve description of default privileges
Date
Msg-id alpine.DEB.2.21.1809290937200.10583@lancre
Whole thread Raw
In response to Re: doc - improve description of default privileges  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: doc - improve description of default privileges
List pgsql-hackers
> The Owner column is redundant, because it's always all applicable
> privileges.  (Having this column would give the impression that it's not
> always all privileges, so it would be confusing.)

The reason I put the owner column is to show (1) the privileges that apply 
to the objects (i.e. what is under "ALL") and (2) whether public's 
privileges are the same or not, because there are subtles differences, so 
I think it is interesting to have them side by side somewhere.

> Privileges should be listed using their full name (e.g., "SELECT"), not
> their internal abbreviation letter.

Hmmm... the psql commands listed in the table output the abbreviated 
letters. Using the words would result in a large table, but maybe it 
could use multiline cells.

> The psql commands seem out of place here.  If you want to learn about
> how to use psql, you can go to the psql documentation.

The information about how to display the permissions is currently not 
easily available, I had to test/look for it, noticed that it is not 
accessible on some objects, so ISTM that it is useful to have it 
somewhere.

Basically your points suggest that the table is maybe in the wrong place
and could be improved.

About the place, there is no simple choice:

  - backslash commands are "psql" specific
  - abbreviated letters are aclitem function specific, which
    happend to be used by psql.
  - full names are SQL specific (GRANT)
  - default permissions are object specific and can be modified...

Which means that the information tends to be scattered everywhere and 
overall pretty unclear unless you have read all the pages, hence my 
proposal to put some unified summary somewhere with all the relevant 
information. Any choice will have its downside, and removing information 
to better suit one place means that my point of having some kind of 
summary in one place is lost, which is the initial motivation for this 
patch.

-- 
Fabien.


pgsql-hackers by date:

Previous
From: Matteo Beccati
Date:
Subject: Re: [HACKERS] kqueue
Next
From: Michael Paquier
Date:
Subject: Re: Use durable_unlink for .ready and .done files for WAL segmentremoval