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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
