On Mon, 2008-05-26 at 19:11 +0100, Heikki Linnakangas wrote:
> I think it's a good candidate for inclusion in core. Obviously it's not
> ready for that yet, but it does seem that a complete solution, with
> joins etc., can't be achieved purely with user-defined operators.
Joins can be acheived with user-defined operators by using overlaps and
intersection. However, it's ugly enough that not many people would
actually use them.
> > 2. If it should be included in core, I'd like to know if any changes
> > should be made to the API, available operators, or the names of anything
> > (see the reference docs). The current name of the type is "period" to
> > avoid confusion with SQL's misnamed "interval" type. The operators are
> > mostly self-explanatory, but I'm open to suggestion for better names for
> > those, too.
>
> Instead of one datatype, I'd like to see the capability of defining
> period types based on any datatype with suitable opclass. Periods of
> dates and floats, for example, would be just as useful as periods of
> timestamps.
I agree, although we couldn't use the word "period" to describe floats
(at least, that's not how I understand the word).
Do we have any mechanism for that kind of a type generator? Typmod might
work, although that seems awkward.
> > 4. Should we replace the undocumented type "tinterval"?
>
> I didn't realize we have one. It seems that tinterval provides operators
> like overlaps and contains as well. What's the difference between what
> you're working on and tinterval?
"period" is based on timestamptz, "tinterval" is based on "abstime".
Also, my type can be inclusive or exclusive as needed, I couldn't find a
way to make "tinterval" exclusive on either side.
Regards,Jeff Davis
