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 1rbWlv-00FmNj-0P for pgsql-bugs@arkaria.postgresql.org; Sun, 18 Feb 2024 02:19:15 +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 1rbWlt-0091Jc-25 for pgsql-bugs@arkaria.postgresql.org; Sun, 18 Feb 2024 02:19:13 +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 1rbWls-0091JN-PY for pgsql-bugs@lists.postgresql.org; Sun, 18 Feb 2024 02:19:12 +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 1rbWlq-007IXZ-4J for pgsql-bugs@lists.postgresql.org; Sun, 18 Feb 2024 02:19:11 +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 41I2J86t3749307; Sat, 17 Feb 2024 21:19:08 -0500 From: Tom Lane To: jian he cc: Francisco Olarte , Michael Bondarenko , pgsql-bugs@lists.postgresql.org, dgrowleyml@gmail.com Subject: Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); In-reply-to: References: <18348-b097a3587dfde8a4@postgresql.org> <3709307.1708201825@sss.pgh.pa.us> Comments: In-reply-to jian he message dated "Sun, 18 Feb 2024 09:48:27 +0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3749305.1708222748.1@sss.pgh.pa.us> Date: Sat, 17 Feb 2024 21:19:08 -0500 Message-ID: <3749306.1708222748@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk jian he writes: > you already mentioned "Not all fields are valid for every input data type". > interval data type don't even have a unit "quarter", > so the following should generate an error? > select extract(quarter from interval '2011 year 12 month 48 hour > 1005min 2 sec 11 ms'); I'm not especially persuaded by that reasoning. Intervals don't have century or millisecond fields either, but we allow extracting those. If your argument is that we shouldn't allow it because we don't take the input INTERVAL '1 quarter', I'd be much more inclined to add that as valid input than to take away existing extract functionality. But I'm dubious about the proposition that extract's list of valid fields should exactly match the set of allowed input units. The semantics aren't really the same (as per the '80 minutes' example) so such a restriction doesn't seem to have much basis in reality. regards, tom lane