Vector type (Re: challenging constraint situation - how do I make it)

From: Alban Hertroys <alban(at)magproductions(dot)nl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kenneth Downs <ken(at)secdat(dot)com>, Harald Armin Massa <haraldarminmassa(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Vector type (Re: challenging constraint situation - how do I make it)
Date: 2006-05-26 08:54:27
Message-ID: 4476C243.1080901@magproductions.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tom Lane wrote:
> Alban Hertroys <alban(at)magproductions(dot)nl> writes:
>>I can see some problems there, as both value and range matter; it'd be
>>similar to determining the uniqueness of an area in a rectangle (though
>>1 dimensional only, of course).
>
> Except that what you want is to forbid overlap, not forbid equality.
> This is not possible with btree-based unique indexes, because btree
> will not like an opclass whose "equality" member is not transitive.

With what I have in mind, both overlap and equality would violate the
unique constraint. I don't quite see why someone'd want to forbid
overlap but to allow equality; isn't not allowing equality the whole
point of a unique constraint?

Yesterday being a holiday, I had some time to look into this. I'm now in
the design phase for a (more general) vector type.
A timespan type is just a special case for timestamps, the vector type
could expand that to integers, reals, points, dates, etc. Anything
scalar, basically, with some distinctions in operators depending on the
type being discrete or not (discrete types could have adjacency
operators, for example).

I haven't looked into what types of index would be suitable, I suppose
that could cause difficulties. OTOH, if neither overlap nor equality are
allowed on a unique index, I'm under the impression that a btree should
just work.

Knowing that I rarely have time to spend on things like this, is here an
appropriate place to discuss design issues or recruiting people for help?

> If you look in the archives you'll find previous discussion of this
> point, including some blue-sky speculation about whether GiST indexes
> could be made to serve the purpose. That's a long way from being a
> solution you could use today, though.

Looks like a good starting place, I should have a look. Any pointers as
to what to look for?

Regards,
--
Alban Hertroys
alban(at)magproductions(dot)nl

magproductions b.v.

T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede

// Integrate Your World //

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Alban Hertroys 2006-05-26 09:25:37 Re: [SQL] (Ab)Using schemas and inheritance
Previous Message surabhi.ahuja 2006-05-26 07:37:56 latest release of 8.0.8