Re: \du quite ugly in 8.4

Could someone clarify why this (from PG 8.4)

# \du
List of roles
Role name | Attributes | Member of
---------------+-------------+------------
admin | Create role | {}
: Create DB
postgres | Superuser | {}
: Create role
: Create DB
someotheruser | | {}
someuser | | {}

is an improvement over this (from PG 8.3)

# \du
List of roles
Role name | Superuser | Create role | Create DB | Connections |
---------------+-----------+-------------+-----------+-------------+------------
admin | no | yes | yes | no limit | {}
postgres | yes | yes | yes | no limit | {}
someotheruser | no | no | no | no limit | {}
someuser | no | no | no | no limit | {}
(4 rows)

The way I see it, a perfectly clear, complete, and legible table has
been turned into a denormalized, unreadable, and ugly pile of ASCII
salad that moreover wastes valuable vertical screen space instead of
using the abundant horizontal screen space.

2009/10/21 Peter Eisentraut <peter_e(at)gmx(dot)net>:
> Could someone clarify why this (from PG 8.4)
>
> # \du
>              List of roles
>   Role name   | Attributes  | Member of
> ---------------+-------------+------------
>  admin         | Create role | {}
>               : Create DB
>  postgres      | Superuser   | {}
>               : Create role
>               : Create DB
>  someotheruser |             | {}
>  someuser      |             | {}
>
> is an improvement over this (from PG 8.3)
>
> # \du
>                                 List of roles
>   Role name   | Superuser | Create role | Create DB | Connections |
> ---------------+-----------+-------------+-----------+-------------+------------
>  admin         | no        | yes         | yes       | no limit    | {}
>  postgres      | yes       | yes         | yes       | no limit    | {}
>  someotheruser | no        | no          | no        | no limit    | {}
>  someuser      | no        | no          | no        | no limit    | {}
> (4 rows)
>
> The way I see it, a perfectly clear, complete, and legible table has
> been turned into a denormalized, unreadable, and ugly pile of ASCII
> salad that moreover wastes valuable vertical screen space instead of
> using the abundant horizontal screen space.
>

I can see a possible advantage in that there is more room to list the
membership items (although I can't see that being useful most of the
time), and it also provides flexibility by providing an undefined list
of attributes compared to a defined list. For example, the new format
allows the display of "No inheritance", something not shown in the old
format.

However, if that is the limit of how this more flexible approach is
being taken advantage of, I'd tend to agree that the previous format
was fine.

Thom

Peter Eisentraut wrote:
> Could someone clarify why this (from PG 8.4)
>
> # \du
> List of roles
> Role name | Attributes | Member of
> ---------------+-------------+------------
> admin | Create role | {}
> : Create DB
> postgres | Superuser | {}
> : Create role
> : Create DB
> someotheruser | | {}
> someuser | | {}
>
> is an improvement over this (from PG 8.3)

The reason it's an improvement of sorts is that there are now more
possible attributes, and if we had kept adding columns it would have
become wider than 80 columns.

If there's a way to have the attributes as a single line,
comma-separated, but that wraps around when exceeding the terminal
width, I'm all for it. We could also use that logic in a lot more
\-commands, so it'd be worthwhile I think.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> The reason it's an improvement of sorts is that there are now more
> possible attributes, and if we had kept adding columns it would have
> become wider than 80 columns.

Yeah, 8.4 has two more possible entries, and adding them as separate
columns would have guaranteed that the display doesn't fit in 80 cols.

> If there's a way to have the attributes as a single line,
> comma-separated, but that wraps around when exceeding the terminal
> width, I'm all for it. We could also use that logic in a lot more
> \-commands, so it'd be worthwhile I think.

The hard part of that is the "wrap" bit. I wonder how badly we need
that part though. If we just made it comma-separated instead of
newline-separated, it would be a trivial code change, and I bet it would
still look okay for the typical case where the user has only a subset of
these properties.

regards, tom lane

On ons, 2009-10-21 at 10:28 -0300, Alvaro Herrera wrote:
> Peter Eisentraut wrote:
> > Could someone clarify why this (from PG 8.4)
> >
> > # \du
> > List of roles
> > Role name | Attributes | Member of
> > ---------------+-------------+------------
> > admin | Create role | {}
> > : Create DB
> > postgres | Superuser | {}
> > : Create role
> > : Create DB
> > someotheruser | | {}
> > someuser | | {}
> >
> > is an improvement over this (from PG 8.3)
>
> The reason it's an improvement of sorts is that there are now more
> possible attributes, and if we had kept adding columns it would have
> become wider than 80 columns.

How relevant is that 80 columns? I did a mockup using the old design
with two extra columns added and it fit within 100 columns, which still
leaves plenty of horizontal space on the screen.

As a compromise, we could keep the combined "Attributes" column but
replace the line breaks by commas. This would at least get rid of the
confusing and ugly line breaks in the common cases.

> If there's a way to have the attributes as a single line,
> comma-separated, but that wraps around when exceeding the terminal
> width, I'm all for it. We could also use that logic in a lot more
> \-commands, so it'd be worthwhile I think.

Well, the opposite argument could also be made. When the display gets
too long, switch to a wider format.

The argument could be made, however, that it is more important to keep
the relevant information (the role names) on one screen instead of
trying too hard to fit the less important information (the attributes)
on one screen.

Peter Eisentraut wrote:

> As a compromise, we could keep the combined "Attributes" column but
> replace the line breaks by commas. This would at least get rid of the
> confusing and ugly line breaks in the common cases.

That works for me.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

2009/11/2 Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
> Peter Eisentraut wrote:
>> As a compromise, we could keep the combined "Attributes" column but
>> replace the line breaks by commas.  This would at least get rid of the
>> confusing and ugly line breaks in the common cases.
>
> That works for me.

Mmm, perhaps we were a little too hasty about employing the improved
multiline support in psql when we implemented this feature.

I personally don't see what Peter dislikes about the output ... to me
the example he posted is far more readable with linebreaks than it
would be without, but the original thread [1] didn't provoke a lot of
discussion. I think it's likely that a lot of people just plain
missed the thread and are only now seeing the new output as they try
out 8.4. I suppose it's inevitable that some of them won't like it.

Will fewer people take offense if we change it to commas? Perhaps.
It might be worth giving it a try just to see what the reaction is,
but I won't be astonished if we get a similar ratio of people annoyed
by the change regardless of whether we use commas or linebreaks.

Cheers,
BJ

[1] http://archives.postgresql.org/message-id/9543.1203007337@sss.pgh.pa.us