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 i2p603c8f071004091500vbf11365ag2d1954c0673c7380@mail.gmail.com
Whole thread Raw
In response to Re: extended operator classes vs. type interfaces  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: extended operator classes vs. type interfaces  (Nathan Boley <npboley@gmail.com>)
Re: extended operator classes vs. type interfaces  (Yeb Havinga <yebhavinga@gmail.com>)
List pgsql-hackers
On Fri, Apr 9, 2010 at 5:49 PM, Jeff Davis <pgsql@j-davis.com> wrote:
>> 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().

The advantage of specifying a + and a - in the type interface is that
the unit definition can then be specified as part of the type
declaration itself.  So you can do:

CREATE TYPE ts_sec AS RANGE OVER timestamp (UNIT = '1s');
CREATE TYPE ts_min AS RANGE OVER timestamp (UNIT = '1m');

All of the stuff about defining + and - is hidden from the user - it's
part of the type interface, which is pre-created.

...Robert


pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: extended operator classes vs. type interfaces
Next
From: Robert Haas
Date:
Subject: Re: GSoC - proposal - Materialized Views in PostgreSQL