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-overlap
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
Jeff Davis 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 nice if it co
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 insid
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 po
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
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 ei
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 fo
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 som
2009/10/29 Scott Bailey :
> 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
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.
11 matches
Mail list logo
