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: