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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Things I don't like about \du's "Attributes" column
Дата
Msg-id CA+TgmoYG7BKV55bwtLm63jc-O_mLzcceUAdeS88t2T-1VpEpig@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Things I don't like about \du's "Attributes" column  (Pavel Luzanov <p.luzanov@postgrespro.ru>)
Ответы Re: Things I don't like about \du's "Attributes" column
Список pgsql-hackers
On Tue, Jul 16, 2024 at 9:48 AM Pavel Luzanov <p.luzanov@postgrespro.ru> wrote:
> Which version of the patch is currently under discussion?
>
> I believe we are talking about the latest v8 patch version. [1]
>
> 1. https://www.postgresql.org/message-id/5341835b-e7be-44dc-b6e5-400e9e3f3c64%40postgrespro.ru

Thanks. For some reason (likely me being dumb) I was having a hard
time finding that in the thread.

On the question of display width, my personal opinion is that the
current patch is worse than what we have now. Right now, if I type
\du, the output fits in an 80-column terminal unless the role names
are quite long, and \du+ fits except for the Description field, which
wraps. With the patch, even \du wraps in an 80-column terminal. "Role
name", "Login," "Attributes," and "Valid until" fit, but "Connection
limit" doesn't. I know some people think optimizing for 80-column
terminals is obsolete in 2024, and I often use a wider window myself,
but I do still appreciate it when I don't have to make the window
wider to read stuff. Especially, if I didn't use + when running a psql
command, I'd prefer for it to fit.

One solution could be to move "Valid until" or "Connection limit" or
both to verbose mode, as proposed by Rafia. But that's also a
regression over what we have now, where the output fits in 80 columns
and includes that information.

I'm starting to have some doubts about whether this effort is really
worthwhile. It seems like what we have right now is a patch which uses
both more horizontal space and more vertical space than the current
implementation, without (IMHO) really offering any clear advantage. I
know this started out as an effort to address Tom's complaints in the
original post, but it feels like we're losing as much as we're
gaining, and Tom seems to have lost interest in the thread, too.

--
Robert Haas
EDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: Removing unneeded self joins
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [EXTERNAL] Re: Add non-blocking version of PQcancel