Re: [HACKERS] Mentors needed urgently for SoC & PostgreSQL Student Internships

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, lembark(at)wrkhors(dot)com, pgsql-hackers(at)postgresql(dot)org, pgsql-www(at)postgresql(dot)org
Subject: Re: [HACKERS] Mentors needed urgently for SoC & PostgreSQL Student Internships
Date: 2009-04-02 18:37:33
Message-ID: 1238697453.29661.13.camel@dell.linuxdev.us.dell.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-04-02 18:38:06 Re: 8.4 open items list
Previous Message Robert Haas 2009-04-02 18:37:21 Re: [HACKERS] string_to_array with empty input

Browse pgsql-www by date

  From Date Subject
Next Message Heikki Linnakangas 2009-04-02 18:58:02 Re: [HACKERS] Mentors needed urgently for SoC & PostgreSQL Student Internships
Previous Message Heikki Linnakangas 2009-04-02 18:19:46 Re: [HACKERS] Mentors needed urgently for SoC & PostgreSQL Student Internships