Jeff Davis wrote:
> On Thu, 2009-04-02 at 21:19 +0300, Heikki Linnakangas wrote:
>> The data type itself is quite trivial. It's all the operators that are
>> more difficult to implement, and also immensely useful. That part is
>> still incomplete.
>
> Can you please let me know what you find lacking (note: the SVN repo is
> the most current one)?
>
> I've implemented a pretty standard set of operators, and a GiST opclass
> to make things like overlaps, etc., indexable.
>
> I have not yet implemented temporal join.
That, and temporal union and difference. You have a union operator, but
that's not enough for a temporal union, as in:
SELECT 'foo', (10, 20) as when
UNION temporal on when -- imaginary syntax..
SELECT 'foo', (15, 30) as when
->
'foo', (10, 30)
Also, it would be nice to generalize the thing so that it works not only
with intervals of time, but also floats, integers, numerics etc. The
concept of an interval is not really tied to timestamps, even though
that's probably the most common use case in the business world.
>> I'd love to see that implemented. I volunteer to mentor if someone wants
>> to tackle it.
>
> A big open question is whether we do new syntax, and if so, what. A lot
> of the literature for temporal types out there (from people basing their
> suggestions on SQL, like Snodgrass, et al., not C.J. Date) suggests
> syntax extensions which seem pretty specialized and unnecessary to me,
> but perhaps convenient.
I can't imagine how you would implement temporal joins and unions
without syntax extensions. If there is a way, that would be great,
because that might allow us to implement them without backend changes.
> The only thing I really think needs better syntax is a constructor that
> can easily represent [ ), [ ], ( ), ( ] -- i.e. inclusive/exclusive.
> Right now I have 4 functions to do that, but it's awkward and overly
> verbose.
Can't the input function handle those? Or you could have just one
constructor with an extra argument indicating whether each end of the
range is exclusive or inclusive.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com