Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lTSAB-0001UY-Qu for pgsql-hackers@arkaria.postgresql.org; Mon, 05 Apr 2021 16:33:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lTSAA-0001Tn-NZ for pgsql-hackers@arkaria.postgresql.org; Mon, 05 Apr 2021 16:33:18 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lTSAA-0001Tg-CE for pgsql-hackers@lists.postgresql.org; Mon, 05 Apr 2021 16:33:18 +0000 Received: from mail-il1-x134.google.com ([2607:f8b0:4864:20::134]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lTSA6-0004aJ-Ej for pgsql-hackers@postgresql.org; Mon, 05 Apr 2021 16:33:17 +0000 Received: by mail-il1-x134.google.com with SMTP id c3so2466049ils.2 for ; Mon, 05 Apr 2021 09:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=xzdD0kUFNwSlMrwZ95ZsoWlKuwyXoYpNaWiBfw0uQ4o=; b=JwksNdzUIfA7wk9TOpQ9HybOOiwxJWQndSP4UPWXOYc726jHs38KnczIS9722FTDQK cNoos3ncteWRMOEODVMEDDLW+wqt1/l9ayNmmkWfUY0SEeJ1Qdv5ThrkRhzKM1+3ZOYW VsH+K/1Wb5vCvDC9uZEw95WTJunC5hya+mZaKHiYRjCvZl783CloURpyzeDs4i8es4C+ P2mw99h2dIIR2lP85hpv1y2a71F6G9TI+p6LvRqHAlp3Ound0C4d5u+TWh1I5FxyU5+N tDQUzZpyzwPxFhrEfmKBjHc7yHoyRvuFfMe6ujzUW54Ul7aOcvXGKPjZv5HOVwZJ3zkj u9Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=xzdD0kUFNwSlMrwZ95ZsoWlKuwyXoYpNaWiBfw0uQ4o=; b=lRBNLtYjTVBOLHC+Uq2mwAKjtMPLZOn0Jr5T8TF7k3/1Uxv6jNQPJ0fT3aqKKziloR 9r+L/wol0oMeDrq7179RzI4faQo+urrrhajQcT2AyBv6H59BtpyzOzhSq/Ej5jNLZa3V ERtipBFi3em5OFUIXXWI1NjWoB0/6vppSFjWh68eeLnJWnU5Z4t0V165/Yp5r08TFOex Y+lLcF7FAuCjvf1Jd4ZipFSc/+8mkWDu6Epu/LfqxOyQm0rXU6hopA1H9rG+vYPF6bU5 gfTFs5esDgT1Z7xDCz6i13ZtajsyegaxxkyDGUvSZoZf33fghSobiqSeflKQ7okufvD4 zbzw== X-Gm-Message-State: AOAM532pnurCoMjTw4RqFCG6W3UWe6ZTogcpN2Nm8lpd2b+Bg1IlxsrQ zTo+HjJYijyD8z4unLmzcvbgmw== X-Google-Smtp-Source: ABdhPJwbPlZaI+wbQG5iypzBRoxky/Shs8Z//IpnkBfOFdSYFB8eI32UO8VsFeQoo0XdyZUbJhJ/mg== X-Received: by 2002:a92:1950:: with SMTP id e16mr8996991ilm.120.1617640392546; Mon, 05 Apr 2021 09:33:12 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id k11sm12715229iok.1.2021.04.05.09.33.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Apr 2021 09:33:12 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 026F1801308; Mon, 5 Apr 2021 11:33:10 -0500 (CDT) Date: Mon, 5 Apr 2021 11:33:10 -0500 From: Justin Pryzby To: Bruce Momjian , Bryn Llewellyn Cc: Zhihong Yu , Isaac Morland , John W Higgins , pgsql-hackers@postgresql.org, Tom Lane Subject: Re: Have I found an interval arithmetic bug? Message-ID: <20210405163310.GP6592@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210403022126.GG29126@momjian.us> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Apr 02, 2021 at 10:21:26PM -0400, Bruce Momjian wrote: > I wish I could figure out how to improve it any futher. What is odd is > that I have never seen this reported as a problem before. I plan to > apply this early next week for PG 14. On Fri, Apr 02, 2021 at 01:05:42PM -0700, Bryn Llewellyn wrote: > bruce@momjian.us wrote: > > Yes, looking at the code, it seems we only spill down to one unit, not more. I think we need to have a discussion if we want to change that. If this is a bug, then there's no deadline - and if you're proposing a behavior change, then I don't think it's a good time to begin the discussion. > https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-INTERVAL-INPUT > « …field values can have fractional parts; for example '1.5 week' or '01:02:03.45'. Such input is converted to the appropriate number of months, days, and seconds for storage. When this would result in a fractional number of months or days, the fraction is added to the lower-order fields using the conversion factors 1 month = 30 days and 1 day = 24 hours. For example, '1.5 month' becomes 1 month and 15 days. Only seconds will ever be shown as fractional on output. » Your patch changes what seems to be the intended behavior, with the test case added by: |commit 57bfb27e60055c10e42b87e68a894720c2f78e70 |Author: Tom Lane |Date: Mon Sep 4 01:26:28 2006 +0000 | | Fix interval input parser so that fractional weeks and months are | cascaded first to days and only what is leftover into seconds. This And documented by: |commit dbf57d31f8d7bf5c058a9fab2a1ccb4a336864ce |Author: Tom Lane |Date: Sun Nov 9 17:09:48 2008 +0000 | | Add some documentation about handling of fractions in interval input. | (It's always worked like this, but we never documented it before.) If you were to change the behavior, I think you'd have to update the documentation, too - but I think that's not a desirable change. I *am* curious why the YEAR, DECADE, CENTURY, AND MILLENIUM cases only handle fractional intervals down to the next smaller unit, and not down to seconds/milliseconds. I wrote a patch to handle that by adding AdjustFractMons(), if we agree that it's desirable to change. -- Justin