| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>, David Fetter <david(at)fetter(dot)org> |
| Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: range_agg |
| Date: | 2019-07-06 19:26:06 |
| Message-ID: | 2ab176f136f0fda560f63cd091875bf21c4fe7df.camel@j-davis.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 2019-07-05 at 10:57 -0700, Paul A Jungwirth wrote:
> I take it that a multirange contains of *disjoint* ranges, so instead
> of {[1,2), [2,3), [6,7)} you'd have {[1,3), [6,7)}. Jeff does that
> match your expectation?
Yes.
> I just realized that since weighted_range_agg and covering_range_agg
> return tuples of (anyrange, integer) (maybe other numeric types
> too?),
> their elements are *not ranges*, so they couldn't return a
> multirange.
> They would have to return an array of those tuples.
I think you are right. I was originally thinking a multirange and an
array of weights would work, but the multirange would coalesce adjacent
ranges because it would have no way to know they have different
weights.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Pryzby | 2019-07-06 20:24:25 | Re: doc: improve PG 12 to_timestamp()/to_date() wording |
| Previous Message | Jeff Davis | 2019-07-06 19:13:08 | Re: range_agg |