Re: range_agg
От | Paul Jungwirth |
---|---|
Тема | Re: range_agg |
Дата | |
Msg-id | 91d7296b-7174-c2bb-8efa-7bfab53a97c4@illuminatedcomputing.com обсуждение исходный текст |
Ответ на | Re: range_agg (Corey Huinker <corey.huinker@gmail.com>) |
Список | 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@illuminatedcomputing.com
В списке pgsql-hackers по дате отправления: