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

On Thu, 2009-04-02 at 21:58 +0300, Heikki Linnakangas wrote:
> > 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:

Ok, so you were talking about the relational operators, not interval
predicates or interval operators. I agree that the relational operators
are non-trivial.

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

Yeah. I thought about how to do that with typmod, but it doesn't allow
storing an entire OID for the constituent types. It may be possible to
work around that.

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

I still didn't know you were talking about relational operators at that
point. Temporal join, union, difference, and also probably table logs
all require syntax (not "require" maybe, but it would help a lot).

The unnecessary syntax I was referring to is the SQL-ish syntax
suggested by Snodgrass, et al, which involves words for things like
"overlaps", which we really don't need.

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

Constructing from a single string is easy. What happens when you want to
say ( 2009-01-01, now() ], or pass a timestamptz from a table?  Ideas
welcome.

Regards,Jeff Davis