Re: extended operator classes vs. type interfaces

On Fri, Apr 9, 2010 at 4:10 AM, Dimitri Fontaine <dfontaine(at)hi-media(dot)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