From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Darren Duncan <darren(at)darrenduncan(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Range Types and extensions |
Date: | 2011-06-06 16:26:46 |
Message-ID: | 1307377606.2402.146.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2011-06-06 16:28:05 | Re: Range Types and extensions |
Previous Message | Kevin Grittner | 2011-06-06 16:23:52 | Re: Postmaster holding unlinked files for pg_largeobject table |