Re: extended operator classes vs. type interfaces - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: extended operator classes vs. type interfaces |
Date | |
Msg-id | z2m603c8f071004090748v599c74a5o21d38e06bfa90739@mail.gmail.com Whole thread Raw |
In response to | Re: extended operator classes vs. type interfaces (Dimitri Fontaine <dfontaine@hi-media.com>) |
List | pgsql-hackers |
On Fri, Apr 9, 2010 at 4:10 AM, Dimitri Fontaine <dfontaine@hi-media.com> wrote: > Do we want to enable support for string based ranges, as in the > contributed prefix_range type? Yes, probably, but that doesn't require as much knowledge of the underlying data type, so I didn't feel it needed to be brought up in this context. There is no x such that ['a','b') = ['a',x]; it's generally impossible to convert between open and closed intervals in this type of range type. That's the case where type interfaces are needed; if you're not converting between different kinds of intervals then you can probably get by with the existing system of using the default btree opclass to find equality and comparison operators. > I like the type interface approach and I think this concept has been > studied in great details in math and that we should start from existing > concepts, even if most of them are way over my head. I'm not too excited about patterning this too closely after mathematical concepts; I think we need to have a pragmatic approach that focuses on what the database actually needs. We need to think generally enough about what we're trying to provide that we don't box ourselves into a corner, but we're not trying to build a theorem-prover. > You'll see in this mail a proposal for an operator group notion, which > could get renamed to type interface if we think we won't need rings and > such rather than just groups in the future. And there's opportunity for > multi-type interfaces too (think families), like what's the distance > between a point and a circle? Yeah, that needs some thought. > The math groups already have a notion of neutral element, which for the > addition is 0 (zero), we could expand our version of it with a "unity" > element, which would be in the T domain. I don't know what that would mean in this case. We're trying to add and subtract from T, so a unit or identity element makes sense for U, but not for T. > Then the range type could expand on this and provide a different unity > value in their own interface, in the U domain this time. IMO tying the > precision of the range interval into the type interface is a bad > abstraction. As you said we want to possibly have several ranges types > atop this. Right - so I think there's no point in specifying this in the type interface at all. We can always add it later if we find a real need for it. > We can say that [1,3] = [1,4) when considering a "default" integer range > because 4-3 = unity(integer). When considering a range over timestamps > with a range interval unity of 1s, we are still able to do the math, and > we can have another range over timestamps with a range interval unity of > 10 mins in the same database. (I'm using this later example with the > period datatype in a real application). > > While speaking of all that, in the prefix_range case, it'd be useful to > have a new kind of typemod system at the range level, to allow for > defining prefix text range with the '/' separator, say. Then > > greater_prefix('/etc/bar', '/etc/baz') = '/etc' (or is it '/etc/'?) > > Whereas currently > > => select '/etc/baz'::prefix_range | '/etc/bar'; > ?column? > -------------- > /etc/ba[r-z] > (1 row) Not sure I'm really following this. ...Robert
pgsql-hackers by date: