Re: Things I don't like about \du's "Attributes" column - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Things I don't like about \du's "Attributes" column
Date
Msg-id CAKFQuwbWd819iFPcE23g9zfJj2Wfi-0rfTsxYjN14rWSWnh3Tw@mail.gmail.com
Whole thread Raw
In response to Re: Things I don't like about \du's "Attributes" column  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, May 14, 2024 at 9:03 AM Robert Haas <robertmhaas@gmail.com> wrote:
On Tue, Apr 16, 2024 at 3:06 AM Pavel Luzanov <p.luzanov@postgrespro.ru> wrote:
> As for the Login column and its values.
> I'm not sure about using "Can" instead of "yes" to represent true.
> In other psql commands, boolean values are always shown as yes/no.
> NULL instead of false might be possible, but I'd rather check if this approach
> has been used elsewhere. I prefer consistency everywhere.

I don't think we can use "Can" to mean "yes". That's going to be
really confusing.

Agreed
 
If I see that the connection limit is labelled as (irrelevant)
I don't know why it's labelled that way and, if it were me, I'd likely
end up looking at the source code to figure out why it's showing it
that way.

Or we'd document what we've done and users that don't want to go looking at source code can just read our specification.


I think we should go back to the v4 version of this patch, minus the
(ignored) stuff.


Agreed, I'm past the point of wanting to have this behave more intelligently rather than a way for people to avoid having to go write a catalog using query themselves.

David J.

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: An improved README experience for PostgreSQL
Next
From: Jacob Burroughs
Date:
Subject: Re: libpq compression (part 3)