Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fitDZ-0002yG-3U for pgsql-hackers@arkaria.postgresql.org; Fri, 27 Jul 2018 03:15:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fitDX-0001ji-BS for pgsql-hackers@arkaria.postgresql.org; Fri, 27 Jul 2018 03:14:59 +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.89) (envelope-from ) id 1fitDX-0001jb-4S for pgsql-hackers@lists.postgresql.org; Fri, 27 Jul 2018 03:14:59 +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.89) (envelope-from ) id 1fitDT-0004Mk-Vw for pgsql-hackers@postgresql.org; Fri, 27 Jul 2018 03:14:58 +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 w6R3Eje8020161; Thu, 26 Jul 2018 23:14:45 -0400 From: Tom Lane To: David Rowley cc: Amit Langote , Rajkumar Raghuwanshi , pgsql-hackers Subject: Re: negative bitmapset member not allowed Error with partition pruning In-reply-to: References: <16590.1532622503@sss.pgh.pa.us> Comments: In-reply-to David Rowley message dated "Fri, 27 Jul 2018 14:42:45 +1200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20159.1532661285.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Jul 2018 23:14:45 -0400 Message-ID: <20160.1532661285@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk David Rowley writes: > On 27 July 2018 at 13:35, Amit Langote w= rote: >> On 2018/07/27 1:28, Tom Lane wrote: >>> (BTW, I'm not sure that it was wise to design bms_add_range to fail fo= r >>> empty ranges. Maybe it'd be better to redefine it as a no-op for >>> upper < lower?) >> FWIW, I was thankful that David those left those checks there, because = it >> helped expose quite a few bugs when writing this code or perhaps that w= as >> his intention to begin with, but maybe he thinks differently now (?). > I think it's more useful to keep as a bug catcher, although I do > understand the thinking behind just having it be a no-op. Well, my thinking is that it helps nobody if call sites have to have explicit workarounds for a totally-arbitrary refusal to handle edge cases in the primitive functions. I do not think that is good software design. If you want to have assertions that particular call sites are specifying nonempty ranges, put those in the call sites where it's important. But as-is, this seems like, say, defining foreach() to blow up on an empty list. regards, tom lane