Date: Wed, 10 Jul 2019 08:24:00 +0200
From: David Fetter <david@fetter.org>
To: Paul A Jungwirth <pj@illuminatedcomputing.com>
Cc: Jeff Davis <pgsql@j-davis.com>,
	Pgsql Hackers <pgsql-hackers@postgresql.org>
Subject: Re: range_agg
Message-ID: <20190710062359.GI24679@fetter.org>
References: <16d71dc8-34cf-5ebd-1ce5-ccd93c0a14f9@illuminatedcomputing.com>
 <ba323e489b98029be5ba2d5c5cbc99795f333f48.camel@j-davis.com>
 <CA+renyX7jsWnyry6SOn-WSgdgQLtyFJ7SLWBVs+oatwQsMzvog@mail.gmail.com>
 <d9f99d9254ff638f82e1e7c91eaca039e9f9df68.camel@j-davis.com>
 <CA+renyU4jt64TtqP+rk_vdERXypBk5LQ+FQLCRcC4j3DVT8jeg@mail.gmail.com>
 <20190709155112.GH24679@fetter.org>
 <CA+renyUX+x5kfmTb20rmQzFm-DfJEdLJmUD4oG-6GcuXXko0cA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CA+renyUX+x5kfmTb20rmQzFm-DfJEdLJmUD4oG-6GcuXXko0cA@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

On Tue, Jul 09, 2019 at 09:40:59AM -0700, Paul A Jungwirth wrote:
> On Tue, Jul 9, 2019 at 8:51 AM David Fetter <david@fetter.org> wrote:
> > > - A multirange type is an extra thing you get when you define a range
> > > (just like how you get a tstzrange[]). Therefore....
> > > - I don't need separate commands to add/drop multirange types. You get
> > > one when you define a range type, and if you drop a range type it gets
> > > dropped automatically.
> >
> > Yay for fewer manual steps!
> 
> Thanks for taking a look and sharing your thoughts!
> 
> > > - You can have a multirange[].
> >
> > I can see how that would fall out of this, but I'm a little puzzled as
> > to what people might use it for. Aggregates, maybe?
> 
> I don't know either, but I thought it was standard to define a T[] for
> every T. Anyway it doesn't seem difficult.
> 
> > > - You can cast from a multirange to an array. The individual ranges
> > > are always sorted in the result array.
> >
> > Is this so people can pick individual ranges out of the multirange,
> > or...?
> 
> Yes. I want this for foreign keys actually, where I construct a
> multirange and ask for just its first range.

I'm sure I'll understand this better once I get my head around
temporal foreign keys.

> > Speaking of casts, it's possible that a multirange is also a
> > range. Would it make sense to have a cast from multirange to range?
> 
> Hmm, that seems strange to me. You don't cast from an array to one of
> its elements. If we have subscripting, why use casting to get the
> first element?

Excellent point.

> > > - Interesting functions:
> > >   - multirange_length
> >
> > Is that the sum of the lengths of the ranges?  Are we guaranteeing a
> > measure in addition to ordering on ranges now?
> 
> Just the number of disjoint ranges in the multirange.

Thanks for clarifying.

> > > - You can subscript a multirange like you do an array (? This could be
> > > a function instead.)
> >
> > How would this play with the generic subscripting patch in flight?
> 
> I'm not aware of that patch but I guess I better check it out. :-)

Looks like I'm the second to mention it. Worth a review?

> > >   - inverse operator?:
> > >     - the inverse of {"[1,2)"} would be {"[null, 1)", "[2, null)"}.
> >
> > Is that the same as ["(∞, ∞)"] - {"[1,2)"}?
> 
> Yes.
> 
> > I seem to recall that the usual convention (at least in math) is
> > to use intervals that are generally represented as open on the
> > infinity side, but that might not fit how we do things.
> 
> I think it does, unless I'm misunderstanding?

Oh, I was just wondering about the square bracket on the left side of
[null, 1).  It's not super important.

> > >     - not sure we want this or what the symbol should be. I don't like
> > > -mr as an inverse because then mr - mr != mr ++ -mr.
> >
> > !mr , perhaps?
> 
> I like that suggestion. Honestly I'm not sure we even want an inverse,
> but it's so important theoretically we should at least consider
> whether it is appropriate here. Or maybe "inverse" is the wrong word
> for this, or there is a different meaning it should have.

Jeff's suggestion of ~ for complement is better.

Best,
David.
-- 
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate