Vector type (Re: challenging constraint situation - how do I make it) - Mailing list pgsql-general

From Alban Hertroys
Subject Vector type (Re: challenging constraint situation - how do I make it)
Date
Msg-id 4476C243.1080901@magproductions.nl
Whole thread Raw
In response to Re: challenging constraint situation - how do I make it  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Vector type (Re: challenging constraint situation - how do I make it)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Tom Lane wrote:
> Alban Hertroys <alban@magproductions.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@magproductions.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 //

pgsql-general by date:

Previous
From: "surabhi.ahuja"
Date:
Subject: latest release of 8.0.8
Next
From: Alban Hertroys
Date:
Subject: Re: [SQL] (Ab)Using schemas and inheritance