From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: extended operator classes vs. type interfaces |
Date: | 2010-04-09 22:00:27 |
Message-ID: | i2p603c8f071004091500vbf11365ag2d1954c0673c7380@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Apr 9, 2010 at 5:49 PM, Jeff Davis <pgsql(at)j-davis(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Kupershmidt | 2010-04-09 22:01:34 | psql's \d display of unique index vs. constraint |
Previous Message | Jeff Davis | 2010-04-09 21:49:32 | Re: extended operator classes vs. type interfaces |