Skip site navigation (1) Skip section navigation (2)

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

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Jeff Davis <pgsql(at)j-davis(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:58:02
Message-ID: 49D50ABA.1050301@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-www
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

In response to

Responses

pgsql-www by date

Next:From: Jeff DavisDate: 2009-04-02 19:40:16
Subject: Re: [HACKERS] Mentors needed urgently for SoC& PostgreSQL Student Internships
Previous:From: Jeff DavisDate: 2009-04-02 18:37:33
Subject: Re: [HACKERS] Mentors needed urgently for SoC &PostgreSQL Student Internships

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-04-02 19:01:38
Subject: Re: fix - function call with variadic parameter for type "any"
Previous:From: Teodor SigaevDate: 2009-04-02 18:52:12
Subject: Re: Crash in gist insertion on pathological box data

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group