On 04.04.2023 22:02, David G. Johnston wrote:
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Apr 4, 2023 at 1:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I wonder if, while we're here, we should apply the idea of
>> joining-with-newlines-not-commas to the attributes column too.
> That would make the column narrower, which might be good, because it
> seems to me that listing the memberships could require quite a lot of
> space, both vertical and horizontal.
Right, that's what I was thinking.
So, by way of example:
regress_du_role1 | cannot login | regress_du_role0 granted by regress_du_admin with admin, inherit, set | Description for regress_du_role1
Perhaps more closely to syntax?
regress_du_role0 with admin, inherit, set granted by regress_du_admin
instead of
regress_du_role0 granted by regress_du_admin with admin, inherit, set
No translations, all words are either identical to syntax or identifiers.
I'm on board with newlines in the attributes field.
+1
The specific member of column changes are:
from -> granted by
( ) -> "with"
ais -> admin, inherit, set
I'm good with any or all of those selections, either as-is or in the more verbose form.
From yesterday's discussion, I think two things are important:
- it is advisable to avoid translation,
- there is no sense in the abbreviation (a,i,s), if there are full names in the 'attributes' column.
So I agree with such changes and plan to implement them.
And one more question. (I think it's better to have it explicitly rejected than to keep silent.)
What if this long output will be available only for \du+, and for \du just show distinct (without duplicates)
roles in the current array format? For those, who don't care about these new membership options, nothing will change.
Those, who need details will use the + modifier.
?
--
Pavel Luzanov
Postgres Professional: https://postgrespro.com
