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 1hNiBi-00006t-UY for pgsql-hackers@arkaria.postgresql.org; Mon, 06 May 2019 18:18:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hNiBh-0003tJ-8I for pgsql-hackers@arkaria.postgresql.org; Mon, 06 May 2019 18:18:05 +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 1hNiBg-0003jc-OD for pgsql-hackers@lists.postgresql.org; Mon, 06 May 2019 18:18:05 +0000 Received: from mail-pf1-x433.google.com ([2607:f8b0:4864:20::433]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hNiBR-00035u-Uf for pgsql-hackers@postgresql.org; Mon, 06 May 2019 18:18:00 +0000 Received: by mail-pf1-x433.google.com with SMTP id l132so2239255pfc.8 for ; Mon, 06 May 2019 11:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=illuminatedcomputing-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=KG/ba0L45jT/PsFI7NUVC+8iHw+vPu3xrAESx95aa0I=; b=ftavCOlnm3j+bIH4tYnM8Rn04RasnCSdblWpXwyEpVxf5XQmPuu2Nw5SxI4sL0K8lq Zx31bVCMfmnqWkr7RhHpYN7PcDlA3voHrlhs/fZhX/KA3NxDyXDbhZPF8zQWiIE3xgHC aB6zrK9y+vSIwgIgEhpnnEwWBiQ4drNuU6WVsJWA0qzijp8Td9kuzZxOfxsqPLh88G1e mekR1o3PjhoawR8vYGcPPNK3oGpV7sMPF7NHjAATP+1gLJNYB9e0TEqJF7cb6D/n54uj mhIxcjA4Mrc+O5vTEwiO5fnWRj514eLnyyxNDnPlLROFdVI+/yQ1aTT2u/kYp187nLbQ PmNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KG/ba0L45jT/PsFI7NUVC+8iHw+vPu3xrAESx95aa0I=; b=HGl2SFTUqlSGyv7gfmZMR+fVy8z7DpLwwweIQdPJsxYanNH5j32+oiplDIHJFnK5sp emdY2QwuKX7y7ScReBNQXfYTwZYE3Ecv2fm1rL2nOsF3SSv/pcoOdq2mUm9MH03taOMT xS2CZTGxl3IwB2T/WqkDLqMKU1uUZPfQxcKugPlwwtr1No3aFwu7G6dIWtNItSud4ZQs FVwbopuugXuo31l9QTCdcucvOqML1ekY6HDVhZv3Arp8J7/BYrX5DLfxJlAYofbdv2/x 7vZodL/iOAkGSSKAbltxvGtVkLXrCn4YVygBlblhOlzx+iEh35Avhi4ry3UK1S8Sx1yI MLIg== X-Gm-Message-State: APjAAAUFxAUh8p1M3JQoB53CVTANLBaf19BsdG4UGzhvdcv5xFhHVKlC P/2MXYVZ5P3jNOWkovfLGPg+K9NZqno= X-Google-Smtp-Source: APXvYqzXO3VMBeVvMKGjneolgol+pRvKUlktxiSeB0lvebaBNVhEEqKfdd8ZhzjGDgru7QJcPc+4hQ== X-Received: by 2002:a65:4589:: with SMTP id o9mr34180726pgq.381.1557166667950; Mon, 06 May 2019 11:17:47 -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 k14sm31137339pfj.171.2019.05.06.11.17.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 May 2019 11:17:47 -0700 (PDT) Subject: Re: range_agg To: Corey Huinker Cc: Pgsql Hackers References: <16d71dc8-34cf-5ebd-1ce5-ccd93c0a14f9@illuminatedcomputing.com> From: Paul Jungwirth Message-ID: <91d7296b-7174-c2bb-8efa-7bfab53a97c4@illuminatedcomputing.com> Date: Mon, 6 May 2019 11:17:46 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: 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 On 5/4/19 3:11 PM, Corey Huinker wrote: > 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: > > > Perhaps a third way would be to allow and preserve the gaps. Thanks for the feedback! I think this is what I'm doing already (returning an array of ranges), but let me know if I'm misunderstanding. My extension has these signatures: range_agg(anyrange) returning anyrange range_agg(anyrange, bool) returning anyarray range_agg(anyrange, bool, bool) returning anyarray. The first variant raises an error if there are gaps or overlaps and always returns a single range, but the other two return an array of ranges. I was planning to use the same signatures for my patch to pg, unless someone thinks they should be different. But I'm starting to wonder if they shouldn't *all* return arrays. I have two concrete use-cases for these functions and they both require the array-returning versions. Is it helpful to have a version that always returns a single range? Or should I make them all consistent? Thanks, -- Paul ~{:-) pj@illuminatedcomputing.com