public inbox for [email protected]  

help / color / mirror / Atom feed

From: Heikki Linnakangas <[email protected]>
To: Jeff Davis <[email protected]>
Cc: Josh Berkus <[email protected]>
Cc: David E. Wheeler <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Subject: Re: [HACKERS] Mentors needed urgently for SoC &	PostgreSQL Student Internships
Date: Thu, 02 Apr 2009 21:58:02 +0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

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

view thread (14+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: [HACKERS] Mentors needed urgently for SoC &	PostgreSQL Student Internships
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox