Skip site navigation (1)
Skip section navigation (2)
## Re: extended operator classes vs. type interfaces

### In response to

### Responses

### pgsql-hackers by date

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

- extended operator classes vs. type interfaces at 2010-04-09 02:29:18 from Robert Haas

- Re: extended operator classes vs. type interfaces at 2010-04-09 14:48:27 from Robert Haas

Next: From:Fujii MasaoDate:2010-04-09 08:18:35Subject: Re: Remaining Streaming Replication Open ItemsPrevious: From: Greg StarkDate: 2010-04-09 03:51:45Subject: Re: a faster compression algorithm for pg_dump