Jeff Davis wrote:
> The advantages of including it in core are that some features can't be
> done from pgfoundry, such as:
> * temporal foreign keys
> * temporal joins
> * syntax like "ALTER TABLE ... ADD LOG".
> On the other hand, I don't currently have proposals for any of those
> things. And including in core has the usual drawbacks, like waiting for
> a new PostgreSQL release just to get some improvement for the data type.
>
> 1. Should it be included in core, or remain on pgfoundry?
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.
> 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.
> 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?
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
