From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Pavel Luzanov <p(dot)luzanov(at)postgrespro(dot)ru> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jim Nasby <jim(dot)nasby(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Things I don't like about \du's "Attributes" column |
Date: | 2024-06-07 12:35:14 |
Message-ID: | CA+TgmoaRx_awosA6yngkNFyb3wKGbQ=z8UjFpwvdtar8HLVZpg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jun 6, 2024 at 5:10 PM Pavel Luzanov <p(dot)luzanov(at)postgrespro(dot)ru> wrote:
> Agree.
> There is an additional technical argument for removing this replacement.
> I don't like explicit cast to text of the "Connection limit" column.
> Without 'Not allowed' it is no longer required.
> Value -1 can be replaced by NULL with an implicit cast to integer.
Yeah, +1 for that idea.
> Example output:
>
> \du+ regress_du*
> List of roles
> Role name | Login | Attributes | Valid until | Connection limit | Description
> ------------------+-------+-------------+------------------------------+------------------+------------------
> regress_du_admin | yes | Superuser +| | | some description
> | | Create DB +| | |
> | | Create role+| | |
> | | Inherit +| | |
> | | Replication+| | |
> | | Bypass RLS | | |
> regress_du_role0 | yes | Inherit | Tue Jun 04 00:00:00 2024 PDT | 0 |
> regress_du_role1 | no | Create role+| infinity | |
> | | Inherit | | |
> regress_du_role2 | yes | Inherit +| | 42 |
> | | Replication+| | |
> | | Bypass RLS | | |
> (4 rows)
This seems unobjectionable to me. I am not sure whether it is better
than the current verison, or whether it is what we want. But it seems
reasonable.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2024-06-07 12:37:58 | Re: Conflict Detection and Resolution |
Previous Message | Ashutosh Bapat | 2024-06-07 12:08:49 | Re: Conflict Detection and Resolution |