arta...@comcast.net (Scott Bailey) writes:
Disk format - A period can be represented as [closed-closed],
(open-open), [closed-open) or (open-closed] intervals. Right now we
convert these to the most common form, closed-open and store as two
timestamptz's.
I mentioned this at the 2009 PGCon,
On Wed, 2009-11-04 at 12:08 -0500, Chris Browne wrote:
I'm
a lot less certain about the merits of PK/FK constraints - it is a lot
less obvious what forms of constraints will be able to be applied to
particular applications.
Can you clarify, a little?
A temporal key just means non-overlapping
Jeff Davis pg...@j-davis.com writes:
If I understand what you're saying, you're alluding to a type where you
can do things like:
RANGE(timestamptz)
which would be equivalent to a PERIOD.
The RANGE approach sounds so much better from here, as I have the
prefix_range example nearby... it'd be
I would like to add a temporal contrib module. The most important piece
would be adding a period data type and some support functions. Jeff
Davis and I both have temporal projects on pgFoundry, and we've been
collaborating for a while. But there are some areas we'd like to get
some advice on.
2009/10/29 Scott Bailey arta...@comcast.net:
I would like to add a temporal contrib module. The most important piece
would be adding a period data type and some support functions. Jeff Davis
and I both have temporal projects on pgFoundry, and we've been collaborating
for a while. But there are
Scott Bailey wrote:
I would like to add a temporal contrib module. The most important piece
would be adding a period data type and some support functions. Jeff
Davis and I both have temporal projects on pgFoundry, and we've been
collaborating for a while.
I presume you're going to need some
Heikki Linnakangas wrote:
Scott Bailey wrote:
I would like to add a temporal contrib module.
I'm very pleased to see people working on temporal issues, BTW!
Me too - common use-case and difficult to handle without the right
types/operators.
Nulls - A common use case for periods is for
On Thu, 2009-10-29 at 00:31 -0700, Scott Bailey wrote:
Nulls - A common use case for periods is for modeling valid time. Often
the end point is not known. For instance, you know when an employee has
been hired but the termination time typically wouldn't be known ahead of
time. We can
On Thu, 2009-10-29 at 09:37 +, Richard Huxton wrote:
There are cases where one time is genuinely unknown, and there we need
a null.
The semantics of a period with one side NULL require a more clear
definition. I don't personally see a lot of utility in trying to support
NULL semantics, but
I would like to add a temporal contrib module. The most important piece
would be adding a period data type and some support functions. Jeff
Davis and I both have temporal projects on pgFoundry, and we've been
collaborating for a while.
I presume you're going to need some backend support and
On Thu, 2009-10-29 at 10:54 +0200, Heikki Linnakangas wrote:
I presume you're going to need some backend support and possibly new
syntax for some of the operations, right? That seems more urgent to
discuss than the possible inclusion into contrib.
There are various areas that need work inside
11 matches
Mail list logo
