Re: Range Types and extensions - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Range Types and extensions
Date
Msg-id 1307377606.2402.146.camel@jdavis
Whole thread Raw
In response to Re: Range Types and extensions  (Darren Duncan <darren@darrenduncan.net>)
Responses Re: Range Types and extensions
List pgsql-hackers
On Sun, 2011-06-05 at 21:51 -0700, Darren Duncan wrote:
> Jeff Davis wrote:
> > I'd like to take another look at Range Types and whether part of it
> > should be an extension. Some of these issues relate to extensions in
> > general, not just range types.
> > 
> > First of all, what are the advantages to being in core?
> 
> I believe that ranges aka intervals are widely useful generic types, next after 
> relations/tuples/arrays, and they *should* be supported in core, same as arrays are.

I think we all agree that ranges are important. I am not suggesting that
we sacrifice on the semantics to make it an extension; I'm just trying
to see if involving extensions for some of the approximately 5000 lines
would be a good idea.

> Now assuming that a range/interval value is generally defined in terms of a pair 
> of endpoints of some ordered type (that is, a type for which ORDER BY or RANK or 
> {<,>,<=,>=} etc or LIMIT makes sense), it will be essential that this value is 
> capable of distinguishing open and closed intervals.

Right, it already does that explicitly. I'd appreciate your input on
some of the previous discussion though.

> Also, if Postgres has some concept of type-generic special values -Inf and +Inf 
> (which always sort before or after any other value in the type system), those 
> can be used as endpoints to indicate that the interval is unbounded.

I already introduced +/- infinity to range types. They are not generic
outside of ranges, however -- therefore you can't select the upper bound
of an upper-infinite range.

> Unless you have some other syntax in mind, I suggest lifting the range literal 
> syntax from Perl 6, where ".." is an infix operator building a range between its 
> arguments, and a "^" on either side means that side is open, I think; so there 
> are 4 variants: {..,^..,..^,^..^}.

Oh, interesting syntax. That might make a good operator version of a
constructor. Unfortunately, "." is not valid in an operator name in PG.
Maybe I can use tilde or dash?

> Any operation that wants to deal with a range somehow, such as the BETWEEN 
> syntax, could instead use a range/interval; for example, both of:
> 
>    foo in 1..10

I don't know if it's reasonable to introduce syntax like "in" here.
Maybe we could just still use "between" and it would recognize that the
RHS is a range?


> The LIMIT clause could take a range to specify take and skip count at once.

Interesting idea.

> Array slicing can be done using foo[first..last] or such.

I like that, but we already have foo[3:7], so it might be better not to
introduce redundancy. Too bad I can't use ":" as an operator.

> A random number generator that takes endpoints can take a range argument.

Sounds useful because it would make it more explicit whether the
endpoints are possible results.

> An array or relation of these range can represent ranges with holes, and the 
> general results of range union operations.

Right, that's been brought up before as well. In particular, Scott
Bailey has done some thinking/writing on this topic.

Regards,Jeff Davis



pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Postmaster holding unlinked files for pg_largeobject table
Next
From: Pavel Stehule
Date:
Subject: Re: Range Types and extensions