Re: Proposal: temporal extension "period" data type

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