Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1egJnR-000257-LX for pgsql-hackers@arkaria.postgresql.org; Tue, 30 Jan 2018 00:29:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1egJnP-0005Yu-OG for pgsql-hackers@arkaria.postgresql.org; Tue, 30 Jan 2018 00:29:07 +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 1egJnP-0005Yk-HT for pgsql-hackers@lists.postgresql.org; Tue, 30 Jan 2018 00:29:07 +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 1egJnL-0000ys-4Y for pgsql-hackers@postgresql.org; Tue, 30 Jan 2018 00:29:07 +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 w0U0SxHY018876; Mon, 29 Jan 2018 19:28:59 -0500 From: Tom Lane To: Oliver Ford cc: Erik Rijkers , Pg Hackers Subject: Re: Add RANGE with values and exclusions clauses to the Window Functions In-reply-to: References: <2c084c1c2bf599ceb2afa87874de8bc1@xs4all.nl> <13279.1515535159@sss.pgh.pa.us> <4139.1515567978@sss.pgh.pa.us> <27788.1517069693@sss.pgh.pa.us> <10568.1517261334@sss.pgh.pa.us> ! <14068.1517266223@sss.pgh.pa.us> Comments: In-reply-to Oliver Ford message dated "Mon, 29 Jan 2018 23:05:39 +0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18874.1517272139.1@sss.pgh.pa.us> Date: Mon, 29 Jan 2018 19:28:59 -0500 Message-ID: <18875.1517272139@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Another thing I'm a little confused by is the precise API for the in_range support functions (the lack of any documentation for it doesn't help). I wonder why you chose to provide two support functions per datatype combination rather than one with an additional boolean argument. In fact, it almost seems like the "end" flag could already do the job, though I may be missing something. As-is, it seems like this setup involves a lot of duplicate code and catalog entries ... what are we gaining from that? regards, tom lane