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

From: Pavel Luzanov <p(dot)luzanov(at)postgrespro(dot)ru>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, robertmhaas(at)gmail(dot)com
Cc: david(dot)g(dot)johnston(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, 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-10 19:26:38
Message-ID: 037239ee-5566-48e3-aeab-6763c302b658@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10.06.2024 09:25, Kyotaro Horiguchi wrote:

> I guess that in English, when written as "'Login' = 'yes/no'", it can
> be easily understood. However, in Japanese, "'ログイン' = 'はい/いいえ'"
> looks somewhat awkward and is a bit difficult to understand at a
> glance. "'ログイン' = '可/不可'" (equivalent to "Login is
> 'can/cannot'") sounds more natural in Japanese, but it was rejected
> upthread, and I also don't like 'can/cannot'. To give further
> candidates, "allowed/not allowed" or "granted/denied" can be
> mentioned, and they would be easier to translate, at least to
> Japanese. However, is there a higher likelihood that 'granted/denied'
> will be misunderstood as referring to database permissions?

Thank you for looking into this, translationis important.

What do you think about the following options?

1. Try to find a more appropriate name for the column.
Maybe "Can login?" is better suited for yes/no and Japanese translation?

2. Show the value only for true, for example "Granted" as you suggested.
Do not show the "false" value at all. This will be consistent
with the "Attributes" column, which shows only enabled values.

I would prefer the first option and look for the best name for the column.
The second option can also be implemented if we сhoose a value for 'true'.

BTW, I went through all the \d* commands and looked at how columns with
logical values are displayed. There are two approaches: yes/no and t/f.

yes/no
\dAc "Default?"
\dc "Default?"
\dC "Implicit?"
\dO "Deterministic?"

t/f
\dL "Trusted", "Internal language"
\dRp "All tables", "Inserts" "Updates" "Deletes" "Truncates" "Via root"
\dRs "Enabled", "Binary", "Disable on error", "Password required", "Run as owner?", "Failover"

> Likewise, "'Valid until' = 'infinity'" (equivalent to "'有効期限' = '
> 無限'") also sounds awkward. Maybe that's the same in English. I guess
> that 'unbounded' or 'indefinite' sounds better, and their Japanese
> translation '無期限' also sounds natural. However, I'm not sure we
> want to go to that extent in transforming the table.

'infinity' is the value in the table as any other dates.
As far as I understand, it is not translatable.
So you'll see '有効期限' = 'infinity'.

Butthis can be implemented usingthe followingexpression: case when rolvaliduntil = 'infinity' or rolvaliduntil is null then
'unbounded' -- translatable value
else
rolvaliduntil::pg_catalog.text
end

Or we can hide 'infinity':

case when rolvaliduntil = 'infinity' then
null
else
rolvaliduntil
end

This is a little bit better, but I don't like both. Wewill notbe ableto
distinguishbetween nullandinfinity values inthe table. After all, I
think 'infinity' is a rare case for "Valid until". Whatis the reasonto
set'Validuntil'='infinity'ifthe passwordisunlimitedbydefault? Therefore,
my opinion here is to leave "infinity" as is, but I am open to better
alternatives.

--
Pavel Luzanov
Postgres Professional:https://postgrespro.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Hill 2024-06-10 19:33:30 ODBC Source Downloads Missing
Previous Message Alexander Korotkov 2024-06-10 19:26:16 Re: RFC: adding pytest as a supported test framework