On 2/17/07, Tom Lane [EMAIL PROTECTED] wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
How easy/hard would it be to create unique indexes on tinterval (unique
here meaning non-overlapping) ?
Overlapping is not an equality relation (it fails the transitive law),
so I'm not entirely sure what
On 17/02/07, Warren Turkal [EMAIL PROTECTED] wrote:
PERIOD(INT) is actually listed in the Dr. Snodgrass's book. However, I am not
really sure about the semantics of the type. When would you use a
PERIOD(INT)?
It wouldn't be directly useful for temporal SQL, but I have a number
of tables in a
Dawid Kuroczko [EMAIL PROTECTED] writes:
... Now, assuming UNIQUE INDEX on such table, the order would be preserved
since no two intervals can overlap. And no overlapping data could be inserted
without breaking ovelapivity. And of course non-unique index would
produce garbage (since left
Ühel kenal päeval, L, 2007-02-17 kell 11:26, kirjutas Tom Lane:
Hannu Krosing [EMAIL PROTECTED] writes:
How easy/hard would it be to create unique indexes on tinterval (unique
here meaning non-overlapping) ?
Overlapping is not an equality relation (it fails the transitive law),
so I'm not
On Sun, Feb 18, 2007 at 08:14:00PM +0200, Hannu Krosing wrote:
but I can promise you you can't make it work with btree.
Sorry to hear that. btree seemed like the best candidate for doing it.
The problem with btree is that it's designed to work with a compare
function which compares two
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Well, unique is usually defined as not equal to any other. And not
equal also fails transitive law [...]
But it should be trivial to test at insertion time if the interval
overlaps with any existing intervals [...]
Putting your point another
Ühel kenal päeval, R, 2007-02-16 kell 17:39, kirjutas Alvaro Herrera:
Jim C. Nasby wrote:
My suggestion would be to focus on a period data type first and
foremost, as that's something that could be readily used by a lot of
folks. Of particular note, it's difficult to query tables that have
Hannu Krosing [EMAIL PROTECTED] writes:
How easy/hard would it be to create unique indexes on tinterval (unique
here meaning non-overlapping) ?
Overlapping is not an equality relation (it fails the transitive law),
so I'm not entirely sure what unique means in this context ... but I
can promise
On Saturday 17 February 2007 01:50, Hannu Krosing wrote:
Is tinterval meant to be open/closed at start and end ?
I don't see the tinterval doing anything other than storing two times.
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 9: In
On Saturday 17 February 2007 09:26, Tom Lane wrote:
Overlapping is not an equality relation (it fails the transitive law),
so I'm not entirely sure what unique means in this context ... but I
can promise you you can't make it work with btree.
There is an equality relation on periods. But it
On Sat, Feb 17, 2007 at 11:40:44AM -0700, Warren Turkal wrote:
On Saturday 17 February 2007 09:26, Tom Lane wrote:
Overlapping is not an equality relation (it fails the transitive law),
so I'm not entirely sure what unique means in this context ... but I
can promise you you can't make it
My suggestion would be to focus on a period data type first and
foremost, as that's something that could be readily used by a lot of
folks. Of particular note, it's difficult to query tables that have
start_time and end_time fields to define a period; it's easy to screw up
the boundary conditions,
Jim C. Nasby wrote:
My suggestion would be to focus on a period data type first and
foremost, as that's something that could be readily used by a lot of
folks. Of particular note, it's difficult to query tables that have
start_time and end_time fields to define a period; it's easy to screw up
On Fri, Feb 16, 2007 at 05:39:24PM -0300, Alvaro Herrera wrote:
FWIW there's already a type called tinterval that stores (start,end). I
don't think it's very much documented; maybe it can be extended or used
as base for a new, more complete and robust type, indexable in a more
natural way,
On Fri, 16 Feb 2007, Alvaro Herrera wrote:
Jim C. Nasby wrote:
My suggestion would be to focus on a period data type first and
foremost, as that's something that could be readily used by a lot of
folks. Of particular note, it's difficult to query tables that have
start_time and end_time fields
Temporal Extensions for PostgreSQL
by: Warren Turkal
I would like to see a comprehensive solution to time varying tables (or
temporal) in PostgreSQL. I specifically want to see suuport for valid-time and
transacation-time and bitemporal (valid-time and transaction-time) tables. I
will be defering
16 matches
Mail list logo
