Hello Kyotaro-san,
>> Note that 'No privileges' could be somehow interpreted as "default
>> privileges" (no "special/given" privileges) or as "no permissions at
>> all", so there is still some ambiguity, at least for me.
>
> FWIW "No privileges" seems to me as "The user cannot access it at
> all" with no ambiguity.
Ok. For me '' and 'No privileges' still looks like they mean the same,
whereas the point of the patch is to solve the ambiguity.
> Currently the behavior is documented here. (This needs to be
> edited.)
>
> https://www.postgresql.org/docs/10/static/sql-grant.html
Sure, but user friendlyness would suggest that the output should not be
misleading from the start.
> So it changes the existing documented behavior.
Sure. The behavior is misleading, and documentation is of little help in
such a case.
> \dp is a convenient shortcut for users so the output should be
> intuitive or easy-to-grasp.
Yes!
> [...]
>
> relacl | Access privileges
> --------+------------------
> (null) | '(default)'
> {} | '(no privilege)'
This suggestion is better as it avoids the "empty/no" ambiguity. It breaks
the documented behavior, but I'm fine with that anyway.
The human I am now has to know what "default" permissions are depending on
the kind of object, where it could have said it to me directly. Moreover,
the line is not self-contained because the default permission depends on
the owner, but "\dp" does not tell who the owner is, which is another
annoyance.
A benefit of your approach is that its coding is easy because it does not
have to fetch the owner tuple and reconstruct the default perms depending
on the kind of object.
A cleaner approach would be to have a NOT NULL column and have the default
always explicit, instead of having a lazy instantiation of the field
managed on GRANT/REVOKE but not on initialization. However this is
probably too big a change for the problem at hand, and it would not solve
the ambiguity issue for previous versions.
--
Fabien.
