Re: range_agg - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: range_agg
Date
Msg-id CAKFQuwbc9eHwuU3vmdCWuhCtdVzPvOaivzYk7xi4HsYsrGXgrQ@mail.gmail.com
Whole thread Raw
In response to Re: range_agg  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Fri, Dec 20, 2019 at 10:43 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
I took the liberty of rebasing this series on top of recent branch
master.

In the tests there is:

+select '{[a,a],[b,b]}'::textmultirange;
+ textmultirange
+----------------
+ {[a,a],[b,b]}
+(1 row)
+
+-- without canonicalization, we can't join these:
+select '{[a,a], [b,b]}'::textmultirange;
+ textmultirange
+----------------
+ {[a,a],[b,b]}
+(1 row)
+

Aside from the comment they are identical so I'm confused as to why both tests exist - though I suspect it has to do with the fact that the expected result would be {[a,b]} since text is discrete.

Also, the current patch set seems a bit undecided on whether it wants to be truly a multi-range or a range that can report non-contiguous components.  Specifically,

+select '{[a,d), [b,f]}'::textmultirange;
+ textmultirange
+----------------
+ {[a,f]}
+(1 row)

There is a an argument that a multi-range should output {[a,d),[b,f]}.  IMO its arguable that a multi-range container should not try and reduce the number of contained ranges at all.  If that is indeed a desire, which seems like it is, that feature alone goes a long way to support wanting to just merge the desired functionality into the existing range type, where the final output has the minimum number of contiguous ranges possible, rather than having a separate multirange type.

David J.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: range_agg
Next
From: Justin Pryzby
Date:
Subject: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed atend-of-transaction