Re: extended operator classes vs. type interfaces

Hi,

First, I like the way you got back to the needs before trying to
organize an approach to find a solution. Having said it allows me to cut
a lot of your text, it's the one I agree with :)

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Given a type T, I think we'd like to be able to define a type U as
> "the natural type to be added to or subtracted from T". As Jeff
> pointed out to me, this is not necessarily the same as the underlying
> type. For example, if T is a timestamp, U is an interval; if T is a
> numeric, U is also a numeric; if T is a cidr, U is an integer. Then
> we'd like to define a canonical addition operator and a canonical
> subtraction operator. I think that would be sufficient for the needs
> of RANGE BETWEEN ... PRECEDING AND ... FOLLOWING. It would also be
> nearly sufficient for range types, but in that case you also need to
> specify the unit increment within U - i.e. a "1" value for the
> datatype. It may or may not be worth building the concept of a unit
> increment into the type interface machinery, though: one could imagine
> two different range types built over the same base type with different
> unit increments - e.g. one timestamp range with unit increment = 1s,
> and one with unit increment = 1m. Under the first type [4pm,5pm) =
> [4pm,4:59:59pm], while under the second [4pm,5pm) = [4pm,4:59pm].

Do we want to enable support for string based ranges, as in the
contributed prefix_range type?

> Thoughts?

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.

The ORDER BY problem refers to a metric space, defined by a distance
function. Continuing your proposal the distance function return type
would be of domain U. KNNGist is then a way to use the GiST index to
sort by distance.

http://archives.postgresql.org/pgsql-hackers/2010-02/msg01107.php

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?

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.

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.

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)

Regards,
--
dim