From: | Paul Jungwirth <pj(at)illuminatedcomputing(dot)com> |
---|---|
To: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: range_agg |
Date: | 2019-05-06 18:17:46 |
Message-ID: | 91d7296b-7174-c2bb-8efa-7bfab53a97c4@illuminatedcomputing.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)illuminatedcomputing(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Paul Jungwirth | 2019-05-06 18:19:27 | Re: range_agg |
Previous Message | Robert Haas | 2019-05-06 18:08:18 | Re: Fixing order of resowner cleanup in 12, for Windows |