Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hMh6p-0000Nt-Ge for pgsql-hackers@arkaria.postgresql.org; Fri, 03 May 2019 22:56:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hMh6m-00024c-MW for pgsql-hackers@arkaria.postgresql.org; Fri, 03 May 2019 22:56:48 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hMh6m-0001zy-7v for pgsql-hackers@lists.postgresql.org; Fri, 03 May 2019 22:56:48 +0000 Received: from mail-pf1-x42c.google.com ([2607:f8b0:4864:20::42c]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hMh6j-0006bU-Bt for pgsql-hackers@postgresql.org; Fri, 03 May 2019 22:56:46 +0000 Received: by mail-pf1-x42c.google.com with SMTP id 10so3597668pfo.5 for ; Fri, 03 May 2019 15:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=illuminatedcomputing-com.20150623.gappssmtp.com; s=20150623; h=from:subject:to:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=gHEQxctdsX4iMagtgLa3VFaB5r7IGoQl8PimGTV9axc=; b=SD5Rvru8wOqOCtWNcnuqiRrlPJm0iMhDOqIG9o+Z9C7FbNXbfDIrA+iLcDI6ieu2da mbKMqsL9+I0GUBtWHquHrYdyqP0JW0I98/bgPZOyeNJsln6fscTF4qm6NoYQOpQQmsSS zmJbKpv0lUBbTNb6kDCJ/WCi+1TyAjkK0KkZYLNtZUT75Jmi1ORHrnJh6kZH31bNaNaK +XpY4ETfVfOelUGmd2Xwyw1RE6ZX4Y96SGidbBkRC9TbANlyL9Y4Uv5rw5VcT2RTS49f ro5s1b1brYYnFAOyyd1bIBn7e5Kk0LuEub0DQ+vMmqgo6TYsVZrzRdvpplvNGGXHds63 OAsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=gHEQxctdsX4iMagtgLa3VFaB5r7IGoQl8PimGTV9axc=; b=N2SexcHQHYMvwwdEU7wChy34rJ0chLxLS0o3GfeMytxeOQ7Q1C/lptxSTJyp9sbx8d kUPkpSylcwvSDp3s1/x4JMm3ZCysUTrjs5EjXLJPJwX3+3m++O7/xneLfvvB+dbfywPc WHDHQK1v5PblLlzwYb/NBXAsIFnCfp9/CclD2T5fEAcL1C6ItvX8A/lJQdIdM7fNFwk/ 2uTv0iH9XDZJoU5JsSPHJvDR5VTGsn/qFXOcE43XCdZ/KG+MeS1GrhyFFoi9f7Z0YVgc s2I6yCROMODkWbSu9v6S4zTOk+4EFhdUCERzSuM/edUrEtNVSKVmTm7QVkm46akQFrnM nNKg== X-Gm-Message-State: APjAAAWFKy2Nue8OHaoKjGlh9laABw8705f6UVm3H1QmHNH3JWceTL7W 6lSbu15jmnjp0mgLxeCHUnYtxutTWB0= X-Google-Smtp-Source: APXvYqymzIdgWRiU5BAXqE94jjB3XjTTUE364fETUXx1VVgztG3rldD5s5WNGeABw0jflW69nh2a2A== X-Received: by 2002:a63:dd0f:: with SMTP id t15mr14185728pgg.414.1556924203550; Fri, 03 May 2019 15:56:43 -0700 (PDT) Received: from [192.168.2.201] (static-50-53-109-254.bvtn.or.frontiernet.net. [50.53.109.254]) by smtp.googlemail.com with ESMTPSA id g1sm3847644pge.50.2019.05.03.15.56.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 May 2019 15:56:42 -0700 (PDT) From: Paul Jungwirth Subject: range_agg To: Pgsql Hackers Message-ID: <16d71dc8-34cf-5ebd-1ce5-ccd93c0a14f9@illuminatedcomputing.com> Date: Fri, 3 May 2019 15:56:41 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hello, I wrote an extension to add a range_agg function with similar behavior to existing *_agg functions, and I'm wondering if folks would like to have it in core? Here is the repo: https://github.com/pjungwir/range_agg I'm also working on a patch for temporal foreign keys, and having range_agg would make the FK check easier and faster, which is why I'd like to get it added. But also it just seems useful, like array_agg, json_agg, etc. One question is how to aggregate ranges that would leave gaps and/or overlaps. So in my extension there is a one-param version that forbids gaps & overlaps, but I let you permit them by passing extra parameters, so the signature is: range_agg(r anyrange, permit_gaps boolean, permit_overlaps boolean) Perhaps another useful choice would be to return NULL if a gap/overlap is found, so that each param would have three choices instead of just two: accept the inputs, raise an error, return a NULL. What do people think? I plan to work on a patch regardless, so that I can use it for temporal FKs, but I'd appreciate some feedback on the "user interface". Thanks, -- Paul ~{:-) pj@illuminatedcomputing.com