RE: Re: Re: psql : \dn+ to show default schema privileges

From: 노명석 <stan(dot)num(at)kakaocorp(dot)com>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: RE: Re: Re: psql : \dn+ to show default schema privileges
Date: 2025-05-23 07:44:42
Message-ID: 6830292f3fd76bc6114de334.fadbdcb0412043538ce935325d242616@kakaocorp.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,
While testing, I discovered an issue with the \dn+ command's output for schema privileges.
When \dn+ is executed:

For a schema in its initial state where nspacl is (null), the "Access privileges" field appears empty.
After executing REVOKE ALL ON SCHEMA schema_name FROM owner_role;, which changes the nspacl value in pg_namespace to {}, the "Access privileges" field in the \dn+ output is still similarly empty.

Here's an example illustrating this:
Output from SELECT tableoid, oid, nspname, nspowner::regrole, nspacl, acldefault FROM pg_namespace WHERE nspname IN ('schema1', 'stan1'); (assuming stan is the owner of schema1 and test is the owner of stan1 for this example):

tableoid | oid | nspname | nspowner | nspacl | acldefault
----------+-------+-----------+----------+-------------------------------------+------------------
2615 | 41813 | schema1 | stan | {} | {stan=UC/stan}
2615 | 41777 | stan1 | test | (null) | {test=UC/test}

Output from \dn+ schema1 stan1:

List of schemas
Name | Owner | Access privileges | Description
---------+-------+---------------------+--------------------
schema1 | stan | |
stan1 | test | |

As you can see, \dn+ shows an empty "Access privileges" field for schema1 (where nspacl is {}) and for stan1 (where nspacl is (null)).
This makes it difficult to distinguish between a schema with no explicit ACL entries (relying on defaults or owner privileges) and a schema where all privileges have been explicitly revoked.
 
For reasons like this, I believe the display method for schema privileges in \dn+ should be changed or improved to provide better clarity between these different states.
 
-----------------------원본 메세지-----------------------
보낸사람: "Laurenz Albe"<laurenz(dot)albe(at)cybertec(dot)at>
받는사람: "노명석" <stan(dot)num(at)kakaocorp(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
보낸날짜: 2025-05-21 21:52:13 GMT +0900 (Asia/Seoul)
제목: Re: Re: psql : \dn+ to show default schema privileges
 
 
On Wed, 2025-05-21 at 17:26 +0900, 노명석 wrote:
> You've raised valid concerns about hiding information (the actual NULL
> status of nspacl) and the potential for a (small) compatibility break
> if psql were to display default ACLs when nspacl is NULL. This leads
> me to think: if there's an information discrepancy when the actual
> value is NULL but the display shows the default ACL, then wouldn't
> explicitly adding the default ACL to nspacl during CREATE SCHEMA
> itself (instead of leaving it NULL by default) pose an even greater
> risk of more significant compatibility issues? I agree that this isn't
> something that can be changed easily.
 
The behavior is the same if there is a NULL or the explicit default
value in "nspacl". So the information that you are missing if you
don't get to see the default value is marginal - essentially that
someone has granted or revoked privileges on that object.
 
The change in the "psql" output (that might surprise experienced
users) is the bigger concern in my opinion. But it is not a very big
concern either.
 
> Separately, regarding my initial point in the first email about schema
> owner privileges not being included in the output of pg_dump – do you
> think it would be better to send a separate email to suggest adding an
> explanation for this to the documentation?
 
I think that is unnecessary. "pg_dump" doesn't need to preserve
everything literally, as long as the behavior is not changed.
 
But that's just my opinion.
 
Yours,
Laurenz Albe
 

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Álvaro Herrera 2025-05-23 07:54:54 Re: PG 18 release notes draft committed
Previous Message Jim Jones 2025-05-23 07:31:07 Re: XMLSerialize: version and explicit XML declaration