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 1sP1Qi-002VP4-Gw for pgsql-docs@arkaria.postgresql.org; Wed, 03 Jul 2024 14:57:56 +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 1sP1Qg-00A8yW-GS for pgsql-docs@arkaria.postgresql.org; Wed, 03 Jul 2024 14:57:55 +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 1sP1Qg-00A8yO-8y for pgsql-docs@lists.postgresql.org; Wed, 03 Jul 2024 14:57:54 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sP1Qe-000Eg3-Lh for pgsql-docs@lists.postgresql.org; Wed, 03 Jul 2024 14:57:54 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 463EvmQH3251852; Wed, 3 Jul 2024 10:57:48 -0400 From: Tom Lane To: Peter Eisentraut cc: =?UTF-8?B?TmF2csOhdGlsLCBPbmTFmWVq?= , pgsql-docs@lists.postgresql.org Subject: Re: COALESCE documentation In-reply-to: <62f888dc-1ee5-48cf-b76c-6a75dcfa8b10@eisentraut.org> References: <62f888dc-1ee5-48cf-b76c-6a75dcfa8b10@eisentraut.org> Comments: In-reply-to Peter Eisentraut message dated "Wed, 03 Jul 2024 11:00:17 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3251850.1720018668.1@sss.pgh.pa.us> Date: Wed, 03 Jul 2024 10:57:48 -0400 Message-ID: <3251851.1720018668@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Peter Eisentraut writes: > I think this is actually a bug in the implementation, not in the > documentation. That is, the implementation should behave like the > documentation suggests. The trouble with that is that it presumes that the standard's definition of IS NOT NULL is not broken. I think it *is* broken for rowtypes; it certainly cannot be claimed to be intuitive. We already have disclaimers about that in our documentation about IS [NOT] NULL. I don't really want to propagate similar confusion into COALESCE, much less everyplace else that this'd matter. Having said that, I'm not sure that substituting "is distinct from null" in the COALESCE documentation is much better, because it's not clear to me that we're entirely standards-compliant about what that means for rowtypes either. regards, tom lane