Re: Usability fail with psql's \dp command

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Usability fail with psql's \dp command
Date: 2018-07-31 18:54:26
Message-ID: alpine.DEB.2.21.1807311438470.6919@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> One idea is to replace a null ACL value with the actual effective
> permissions, which we could get from the acldefault() function.
> However, acldefault() only exists since 9.2, and in any case
> I'm afraid that might be perceived as mostly clutter.

Here is an poc implementation of this which does not rely on
"acldefault()". Cannot say I'm thrilled, but it is not too bad either. I
worked around \ddp with a recursion.

Writing this piece code makes me realize once again the abysmal coverage
of psql non-regression tests, where basically no \d* functions are tested.
I think at least this part could be salvage from the patch.

Another benefit of expliciting the defaults is that the documentation can
be made more straightforward: shown permissions means what you can see,
which simplifies the description.

Another implementation approach could be to use acldefault() from 9.2, and
just display (no privileges) and (default privileges) before, as suggested
on the thread. This would probably help simplify the code.

I find that having "default privileges" written as not very helpful,
because you have to remember them. Ok, it is all perms for the owner, but
then there are some objects which also have some permissions to public,
and do not memorize these exception. Also, some \d* (eg \dT \dD) do not
display the owner.

I do not perceive as "clutter" the fact that a column advertising "Access
privileges" provides the access privileges... Mostly it is shown only
under "+"; For \dp, you ask for it, you get it.


Attachment Content-Type Size
psql-describe-default-perms-1.patch text/plain 72.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-07-31 18:58:13 Re: patch to ensure logical decoding errors early
Previous Message Dave Cramer 2018-07-31 18:51:12 patch to ensure logical decoding errors early