RE: Re: psql : \dn+ to show default schema privileges - Mailing list pgsql-hackers

From 노명석
Subject RE: Re: psql : \dn+ to show default schema privileges
Date
Msg-id 682d8fcc3fe75d502df2a9aa.ea49e48e373a4ca696bafce5b86a5417@kakaocorp.com
Whole thread Raw
In response to Re: psql : \dn+ to show default schema privileges  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: Re: psql : \dn+ to show default schema privileges
List pgsql-hackers

Dear Laurenz,

First of all, thank you for agreeing with my point about reducing confusion for users.

I hadn't noticed that the documentation already clarifies the meaning of an empty "Access privileges" column.

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.

 

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?

 

Yours,

Myeongseok Noh

 

-----------------------원본 메세지-----------------------
보낸사람: "Laurenz Albe"<laurenz.albe@cybertec.at>
받는사람: "노명석" <stan.num@kakaocorp.com>, pgsql-hackers@lists.postgresql.org
보낸날짜: 2025-05-21 16:59:24 GMT +0900 (Asia/Seoul)
제목: Re: psql : \dn+ to show default schema privileges

 

 

On Wed, 2025-05-21 at 15:33 +0900, 노명석 wrote:

> I propose an enhancement to psql \dn+ to display default schema

> privileges when nspacl is NULL, by using COALESCE with

> pg_catalog.acldefault('n', n.nspowner).

>

> Currently, \dn+ shows NULL for "Access privileges" if a schema's

> ACLs haven't been explicitly altered. This can be misleading

> after a pg_dump/pg_restore operation, as pg_dump correctly omits

> GRANT statements for inherent owner privileges. On the new

> cluster, \dn+ then displays NULL, suggesting to operators that

> owner privileges might have been lost.

 

I agree that showing the default privileges would reduce the

confusion for novice users, which is a good thing.

 

On the other hand, it would hide some information (namely, if there

is a NULL value in the ACL column or not), and it would constitute

a (small) compatibility break. So I am not sure what is better.

 

The current behavior is well documented:

 

If the “Access privileges” column is empty for a given object,

it means the object has default privileges (that is, its

privileges entry in the relevant system catalog is null).

Default privileges always include all privileges for the owner,

and can include some privileges for PUBLIC depending on the

object type, as explained above.

 

Yours,

Laurenz Albe

 

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Allow reading LSN written by walreciever, but not flushed yet
Next
From: Andrey Borodin
Date:
Subject: Re: Allow reading LSN written by walreciever, but not flushed yet