Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rJtQr-00Gk35-9Q for pgsql-hackers@arkaria.postgresql.org; Sun, 31 Dec 2023 10:52:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rJtQn-007FUj-Ix for pgsql-hackers@arkaria.postgresql.org; Sun, 31 Dec 2023 10:52:33 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rJtQn-007FUb-4N for pgsql-hackers@lists.postgresql.org; Sun, 31 Dec 2023 10:52:33 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rJtQk-00EoMB-Rx for pgsql-hackers@lists.postgresql.org; Sun, 31 Dec 2023 10:52:32 +0000 Received: from [192.168.0.104] (unknown [62.217.189.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: p.luzanov@postgrespro.ru) by mail.postgrespro.ru (Postfix/587) with ESMTPSA id BDCE6E21059; Sun, 31 Dec 2023 13:52:28 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1704019948; bh=Ta80bCq7za4xM1ECPytZHQRJnnV+sNP8obpkEKBJHes=; h=Message-ID:Date:User-Agent:Subject:To:Cc:References:From: In-Reply-To:From; b=ihM3K/xn3cATNU+zHsQSNrOIOeti3NOvZlDgZ4dSOSsFHQuIpKBuBbS4JxWiIrkXX AnZV8BCY/IEfOuXNTOQRHEW+433U/ndrTfXB0OeIVuIkPdyibVDczphC7jtkwk5RlX Ya2hnu0noKCuVoc+LGs479fEPojcV9tCjNIuIsLVULmvMDY7/ckVfi6niQ6o4MfbvQ rOfjf4yvYk46oBceSve+cCP4wihQgyofhVTeA4ZN3yv6vTn4Vt/6fCeSS9GjMSgUNO 21ClbMJdPDkxbW6+qh8yG/bFux43SJzRjtx+BzKaWr+YHbldFLX5XNiyWn4gr9tFRR zD00SlvRq9RKw== Content-Type: multipart/alternative; boundary="------------7r45rQnMKk7KdMoX0R05czkp" Message-ID: <6fbfb5ce-5613-43bf-8a84-3da1c0da4746@postgrespro.ru> Date: Sun, 31 Dec 2023 13:52:28 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Things I don't like about \du's "Attributes" column Content-Language: en-US, ru-RU To: Isaac Morland Cc: Tom Lane , pgsql-hackers@lists.postgresql.org References: <4133242.1687481416@sss.pgh.pa.us> <27f87cb9-229b-478b-81b2-157f94239d55@postgrespro.ru> From: Pavel Luzanov In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------7r45rQnMKk7KdMoX0R05czkp Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 30.12.2023 17:33, Isaac Morland wrote: > Would it make sense to make the column non-nullable and always set it > to infinity when there is no expiry? A password is not required for roles. In many cases, external authentication is used in ph_hba.conf. I think it would be strange to have 'infinity' for roles without a password. Tom suggested to have 'infinity' in the \du output for roles with a password. My doubt is that this will hide the real values (absence of values). So I suggested a separate column 'Has password?' to show roles with password and unmodified column 'Password expire time'. Yes, it's easy to replace NULL with "infinity" for roles with a password, but why? What is the reason for this action? Absence of value for 'expire time' clear indicates that there is no time limit. Also I don't see a practical reasons to execute next command, since it do nothing: ALTER ROLE .. PASSWORD 'infinity'; So I think that in most cases there is no "infinity" in the rolvaliduntil column. But of course, I can be wrong. Thank you for giving your opinion. -- Pavel Luzanov Postgres Professional:https://postgrespro.com --------------7r45rQnMKk7KdMoX0R05czkp Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit On 30.12.2023 17:33, Isaac Morland wrote:
Would it make sense to make the column non-nullable and always set it to infinity when there is no expiry?

A password is not required for roles. In many cases, external authentication is used in ph_hba.conf.
I think it would be strange to have 'infinity' for roles without a password.

Tom suggested to have 'infinity' in the \du output for roles with a password.
My doubt is that this will hide the real values (absence of values). So I suggested a separate column
'Has password?' to show roles with password and unmodified column 'Password expire time'.

Yes, it's easy to replace NULL with "infinity" for roles with a password, but why?
What is the reason for this action? Absence of value for 'expire time' clear indicates that there is no time limit.
Also I don't see a practical reasons to execute next command,
since it do nothing:

ALTER ROLE .. PASSWORD 'infinity';

So I think that in most cases there is no "infinity" in the rolvaliduntil column.

But of course, I can be wrong.

Thank you for giving your opinion.

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