Re: Things I don't like about \du's "Attributes" column

Hi Pavel,

First, thanks for your dedication to this effort. I always find it
hard to make time for things like psql backslash command improvements,
but I'm glad that we have people in our community who work on such
things.

Second, I think that the threshold question for this patch is: will
users, on average, be happier if this patch gets committed? If the
answer is yes, then the patch should be committed, and if the answer
is no, the patch should not be committed. But I actually don't really
have any clear idea of what users in general are likely to think. My
own reaction is essentially ... meh. I do not think that the proposed
new output is massively worse than what we have now, but I also don't
think it's a whole lot better. Now, if a bunch of other people show up
and vote, well then we'll have a much better view of what the typical
user is likely to think. But right now, I can't hazard a guess as to
what the general opinion will be, and therefore I'm unprepared to
commit anything. Because, and I can't say this often enough, it's not
all about me. Even if I thought that this patch was way better than
what we have now, I still wouldn't commit it unless I was relatively
confident that other people would agree.

Third, if I can back away from this particular patch for a moment, I
feel like roles and permissions are one of the weaker areas in psql. I
feel, and I suspect most users agree, that the output of "\d my_table"
is top notch. It tells you everything that you need to know about a
particular table -- all the columns, column types, default values,
triggers, indexes, and whatever else there is. If someone adds a new
object that attaches to a table, they're going to understand that they
need to add a listing for that object to the \d output, and users are
going to understand that they should look for it there. That unstated
contract between developers and users is a thing of beauty: without
any words being said, there is a meeting of the minds. But I don't
think the same thing can be said around roles.

For a long time, one of my big gripes in this area has been \z. It
displays information about the permissions of table-like objects. But
I don't really imagine that being a thing that a user is actually
going to want to see. I feel like there are two typical use cases
here. One is you want to see all the privileges associated with a
table. In that case, you'd like the information to show up in the
output of \d or \d+. The other is that you want to see the privileges
associated with a particular user -- and in that case you want to see
not just the table privileges but the privileges on every other kind
of database object, too. I'm not saying there's a single PostgreSQL
user anywhere who has wanted to list information about tables with
names matching a certain wildcard and see just the privilege
information for each one, but I bet it's rare. I also suspect that
only truly hard-core PostgreSQL fans want to see incantations like
"robert.haas"=arwdDxtm/"robert.haas" in their output.

So, personally, if I were going to work on a redesign in this area, I
would look into making \du <username> work like \d <tablename>. That
is, it would tell you every single thing there is to know about a
user. Role attributes. Roles in which this role has membership. Roles
that are a member of this row. Objects of all sorts this object owns.
Permissions this role has on objects of all sorts. Role settings. All
of it in SQL-ish format like we do with the footer when you run \d.
Then I would make \du work like \d: a minimal amount of basic
information about every role in the list, like whether it's a
superuser and whether they can log in. Then, I would consider removing
\dp \drds \drg and \z entirely. I don't know if a plan like that would
actually work out well. A particular problem is that if a user owns
10k objects, we don't want to just list them all one per line. Maybe
when the number of objects owned is large, we could just give a count
per object type unless + is used,  or something like that. But even if
all of this could be sorted out, would users in general like it
better, or would it just make Robert happy? Would even Robert end up
liking the result?

I don't really know, but I think that my general discontent with \du
\dg \dp \drds \drg \z is part of why I find it hard to evaluate a
patch like this. I look forward to seeing the output of "\d <table>"
on whatever table is causing some customer a problem today. I never
look forward to seeing the output of \du. Is that just me?

...Robert