"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
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
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
-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 anot
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 da
Ü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),
>
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
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
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
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
Ü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
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
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,
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
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,
15 matches
Mail list logo
