Re: [HACKERS] Mentors needed urgently for SoC & PostgreSQL Student Internships - Mailing list pgsql-www

From Jeff Davis
Subject Re: [HACKERS] Mentors needed urgently for SoC & PostgreSQL Student Internships
Date
Msg-id 1238697453.29661.13.camel@dell.linuxdev.us.dell.com
Whole thread Raw
In response to Re: [HACKERS] Mentors needed urgently for SoC & PostgreSQL Student Internships  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: [HACKERS] Mentors needed urgently for SoC & PostgreSQL Student Internships  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-www
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.

> I'd recommend a book called Temporal Data and the 
> Relational Model by C.J. Date, Hugh Darwen and Nikos Lorentzos for 
> anyone interested in this topic. That book gives a guideline on how the 
> data type and operators should behave.

Agreed! That is a _very_ good book, and it's what I based my PERIOD type
on (I used to call it t_interval because I agree with Date that's a
better word -- but the conflict with SQL was too great so I changed it).

> 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.

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.

In a related topic, an index that can implement a non-overlapping
constraint is important to temporal databases. I have done some
implementation work on this already, based on my proposal here:

http://archives.postgresql.org//pgsql-hackers/2008-06/msg00404.php

and I have adjusted my design to address some of the concerns Tom brings
up here:

http://archives.postgresql.org//pgsql-hackers/2008-06/msg00427.php

I already have some code written, so if anyone else is thinking of
working on this please contact me first. I will post my progress in the
next couple weeks.

Regards,Jeff Davis








pgsql-www by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: [HACKERS] Mentors needed urgently for SoC & PostgreSQL Student Internships
Next
From: Heikki Linnakangas
Date:
Subject: Re: [HACKERS] Mentors needed urgently for SoC & PostgreSQL Student Internships