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 1s4hmK-000PzY-2N for pgsql-bugs@arkaria.postgresql.org; Wed, 08 May 2024 13:56:16 +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 1s4hmI-0013Jv-AX for pgsql-bugs@arkaria.postgresql.org; Wed, 08 May 2024 13:56:14 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s4hmI-0013JW-16 for pgsql-bugs@lists.postgresql.org; Wed, 08 May 2024 13:56:14 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s4hmF-0001m5-KS for pgsql-bugs@lists.postgresql.org; Wed, 08 May 2024 13:56:12 +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 448DtoPK473945; Wed, 8 May 2024 09:55:51 -0400 From: Tom Lane To: "Wetmore, Matthew (CTR)" cc: Francisco Olarte , Michael Bondarenko , "pgsql-bugs@lists.postgresql.org" , "dgrowleyml@gmail.com" , Peter Eisentraut Subject: Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); In-reply-to: <2219fd69a3024149af5adc31e14b25d7@evernorth.com> References: <18348-b097a3587dfde8a4@postgresql.org> <3709307.1708201825@sss.pgh.pa.us> <3749306.1708222748@sss.pgh.pa.us> <222870.1708458150@sss.pgh.pa.us> <270582.1708462564@sss.pgh.pa.us> <166456.1715117228@sss.pgh.pa.us> <2219fd69a3024149af5adc31e14b25d7@evernorth.com> Comments: In-reply-to "Wetmore, Matthew (CTR)" message dated "Tue, 07 May 2024 22:09:34 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <473943.1715176550.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 08 May 2024 09:55:50 -0400 Message-ID: <473944.1715176550@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "Wetmore, Matthew (CTR)" writes: > Devils advocating here, feel free to ignore. > Is there a real need for a negative month? Sounds like high level this = could be disastrous if I screw up the syntax. (Ah, memories of DD) What are you objecting to the "need for"? That intervals can store negative months at all? I think that ship sailed a couple decades ago. It's hard to use interval as the output of, say, timestamp minus timestamp if it refuses to allow negative values. The next fallback position perhaps could be that extract(quarter ...) could throw error for negative input, but that seems like mostly a foot-gun. We've striven elsewhere to not have it throw error, even if there's not any very sane choice to make. For instance, these are pre-existing behaviors: regression=3D# select extract(quarter from interval 'infinity'); extract = --------- = (1 row) regression=3D# select extract(quarter from interval '-infinity'); extract = --------- = (1 row) Maybe there's a case for returning null for "quarter" for any negative months value, but that seems inconsistent with other behaviors of extract(). The pattern I see for finite values is that negating the input interval negates each output of extract(). regards, tom lane