Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cLxwB-0007CX-TX for pgsql-bugs@arkaria.postgresql.org; Tue, 27 Dec 2016 20:01:32 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cLxwB-00030o-GM for pgsql-bugs@arkaria.postgresql.org; Tue, 27 Dec 2016 20:01:31 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cLxvV-0001Mn-Na for pgsql-bugs@postgresql.org; Tue, 27 Dec 2016 20:00:49 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cLxvT-0004EQ-5n for pgsql-bugs@postgresql.org; Tue, 27 Dec 2016 20:00:49 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id uBRK0hsV031018; Tue, 27 Dec 2016 15:00:44 -0500 From: Tom Lane To: email@piotr-stefaniak.me cc: pgsql-bugs@postgresql.org Subject: Re: BUG #14479: Casting non-constant values to INTERVAL DAY TO MINUTE doesn't truncate the seconds field In-reply-to: <26632.1482862368@sss.pgh.pa.us> References: <20161227172307.10135.7747@wrigleys.postgresql.org> <26632.1482862368@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Tue, 27 Dec 2016 13:12:48 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31016.1482868843.1@sss.pgh.pa.us> Date: Tue, 27 Dec 2016 15:00:43 -0500 Message-ID: <31017.1482868843@sss.pgh.pa.us> X-Pg-Spam-Score: -5.0 (-----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-bugs Precedence: bulk Sender: pgsql-bugs-owner@postgresql.org I wrote: > I've not figured out exactly what's broken about interval_transform; > the bit-twiddling looks a bit fishy, but it may be that that's fine > and there's simply a thinko in the logic about which conversions > are no-ops. There seem to be multiple problems here. One is that this innocent-looking assumption: * Temporally-smaller fields occupy higher positions in the range * bitmap. is bunkum, as a quick look into dt.h confirms: #define MONTH 1 #define YEAR 2 #define DAY 3 #define HOUR 10 #define MINUTE 11 #define SECOND 12 Don't ask me why MONTH was listed before YEAR, but it is, and we don't really have the freedom to change these codes (especially not in the back branches). This function will just have to cope. However, that doesn't impact your specific bug; it means that casting INTERVAL MONTH to INTERVAL YEAR is mistakenly treated as a no-op. The other problem is that it's comparing the result of fls() to the constant SECOND, but that's not right because fls(1 << k) produces k+1 not k. So it's mistakenly reading the cast to INTERVAL DAY TO MINUTE as a cast to INTERVAL DAY TO SECOND, which indeed would be a no-op. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs