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 1rJaPq-00EGrB-3N for pgsql-hackers@arkaria.postgresql.org; Sat, 30 Dec 2023 14:34:18 +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 1rJaPo-000SjO-HS for pgsql-hackers@arkaria.postgresql.org; Sat, 30 Dec 2023 14:34:16 +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 1rJaPo-000ShI-7q for pgsql-hackers@lists.postgresql.org; Sat, 30 Dec 2023 14:34:16 +0000 Received: from mail-pg1-x535.google.com ([2607:f8b0:4864:20::535]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rJaPl-00EfJL-V0 for pgsql-hackers@lists.postgresql.org; Sat, 30 Dec 2023 14:34:15 +0000 Received: by mail-pg1-x535.google.com with SMTP id 41be03b00d2f7-5ce2170b716so3201347a12.1 for ; Sat, 30 Dec 2023 06:34:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703946851; x=1704551651; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=aesvKvI7+5btgvmug/jreo089ljYoEofP1A2iZHBbX4=; b=i9MA0ROb1wBF0xIxylFxnwos+K0sSEEf/Mu6uSBA9BtsliRZH+jbNKgMj0N3Qa2w+2 2jafJ8qW+s2ieO/tgCfGFE/g1i3NxZ0GxUQgL++t+FYfcLQi19g1y0PqRhSik1zI2xt8 1cODZ0iALqJwpFw/8/DwnofqqcYTyB4fG3cdrByA8thcFdSz5gbLOLNciDKqNvJ5kkDR sLlu3wpYWnAzcQC3PbFYNeL+KxcAt2p81A4IpnJcKALzwNJhJtLr/NH5xvoRCezcCEST bpNkBeDTitp4rtOBsiWi3rfIi+a/Ym62W+Q1cnKVHPmW9pO2LvA1hO4VprT0AbpL9vJE laOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703946851; x=1704551651; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=aesvKvI7+5btgvmug/jreo089ljYoEofP1A2iZHBbX4=; b=v53fOSQcH2R6xPPH64+ktBpUgUDGRMtKUHOKWUQIOjQFE2J8tWQ4HpZrfbUhkZtVwq oVJt4bvp9KGBPV2BoRNMbZuS3BABlalveOwHIHkHWjzTwfo0bVKG3ZFJjnCLQQnnTCp7 I7mkDG6dOSPSmJstRWk8KH2Y67Dg+N5h9luzb3g2SizYdkkIchUocZ4Y+ok5amCs45CJ YXSNyPiVPWti8brAz5tzwabidI28JwIxGf4BuyDQN+W0/avzWdhyyMVfygwDm5mSl/aI IHnOGzQLNsJkjTWbWVcdMwH3mEArqta/nFGnMwwRvM0ce8Jp4xLG/xyA8IB6GNfBoKDg bKMQ== X-Gm-Message-State: AOJu0YwHV7QJqJqCSPYzQEipv3PSvmjWWlwvlyK48YuUmR8Im2oyz3BG 4DOy0cbd5elz+9ZNzr0evwdHWrtffdqwEsxhBi4a3/kt X-Google-Smtp-Source: AGHT+IGhRsmp/iFDdPnjHeXxUnPYM0D8DqtXODeFOmOsRsBd4lB/JYkKhcbd3asKfJJI1KpkSYjc4I1E52r+xysO9Lg= X-Received: by 2002:a17:90b:1b49:b0:28a:e560:7ae8 with SMTP id nv9-20020a17090b1b4900b0028ae5607ae8mr6414765pjb.31.1703946851462; Sat, 30 Dec 2023 06:34:11 -0800 (PST) MIME-Version: 1.0 References: <4133242.1687481416@sss.pgh.pa.us> <27f87cb9-229b-478b-81b2-157f94239d55@postgrespro.ru> In-Reply-To: <27f87cb9-229b-478b-81b2-157f94239d55@postgrespro.ru> From: Isaac Morland Date: Sat, 30 Dec 2023 09:33:59 -0500 Message-ID: Subject: Re: Things I don't like about \du's "Attributes" column To: Pavel Luzanov Cc: Tom Lane , pgsql-hackers@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000cc33a2060dbb0a12" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000cc33a2060dbb0a12 Content-Type: text/plain; charset="UTF-8" On Sat, 30 Dec 2023 at 09:23, Pavel Luzanov wrote: > I think that writing the value "infinity" in places where there is no > value is > not a good thing. This hides the real value of the column. In addition, > there is no reason to set "infinity" when the password is always valid with > default NULL. > Would it make sense to make the column non-nullable and always set it to infinity when there is no expiry? In this case, I think NULL simply means infinity, so why not write that? If the timestamp type didn't have infinity, then NULL would be a natural way of saying that there is no expiry, but with infinity as a possible value, I don't see any reason to think of no expiry as being the absence of an expiry time rather than an infinite expiry time. --000000000000cc33a2060dbb0a12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, 30 Dec 2023 at 09:23, Pavel Luzan= ov <p.luzanov@postgrespro.ru= > wrote:
=C2=A0
I think that writing the value "infinity&= quot; in places where there is no value is
not a good thing. This hides the real value of the column. In addition,
there is no reason to set "infinity" when the password is a= lways valid with
default NULL.

Would = it make sense to make the column non-nullable and always set it to infinity= when there is no expiry?

In this case, I think NU= LL simply means infinity, so why not write that? If the timestamp type didn= 't have infinity, then NULL would be a natural way of saying that there= is no expiry, but with infinity as a possible value, I don't see any r= eason to think of no expiry as being the absence of an expiry time rather t= han an infinite expiry time.

--000000000000cc33a2060dbb0a12--