Re: extended operator classes vs. type interfaces

On Thu, 2010-04-08 at 22:29 -0400, Robert Haas wrote:
> 1. knngist wants to use index scans to speed up queries of the form
> SELECT ... ORDER BY <column> <op> <constant> (as opposed to the
> existing machinery which only knows how to use an index for SELECT ...
> ORDER BY <column>).
> 2. Window functions want to define windows over a range of values
> defined by the underlying data type. To do this, we need to define
> what addition and subtraction mean for a particular data type.
> 3. Jeff Davis is interested in implementing range types. When the
> underlying base type is discrete, e.g. integers, you can say that
> [1,3] = [1,4), but only if you know that 3 and 4 are consecutive (in
> that order).

To give some context, I started a thread a while ago:

http://archives.postgresql.org/pgsql-hackers/2009-10/msg01403.php

Tom provided some interesting suggestions in that thread, but I'm not
sure they would work for #1 or #2.

> 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].

Right. Part of the interface could be a unit() function, and that can
return whatever you want.

I was originally thinking about it in terms of next() and prev(), but
you could build those from +, -, and unit().

Regards,
Jeff Davis