Vector type (Re: challenging constraint situation - how do I make it)
От | Alban Hertroys |
---|---|
Тема | Vector type (Re: challenging constraint situation - how do I make it) |
Дата | |
Msg-id | 4476C243.1080901@magproductions.nl обсуждение исходный текст |
Ответ на | Re: challenging constraint situation - how do I make it (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Vector type (Re: challenging constraint situation - how do I make it)
|
Список | 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 по дате отправления: