Re: Things I don't like about \du's "Attributes" column - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: Things I don't like about \du's "Attributes" column |
Date | |
Msg-id | CA+TgmoZ_uGDb3N8AKHG6nOc5HZPp5Y_ogFhrRbhoVnPHN+4t3g@mail.gmail.com Whole thread Raw |
In response to | Re: Things I don't like about \du's "Attributes" column (Pavel Luzanov <p.luzanov@postgrespro.ru>) |
Responses |
Re: Things I don't like about \du's "Attributes" column
|
List | pgsql-hackers |
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
pgsql-hackers by date: