Re: Unique constraints for non-btree indexes - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: Unique constraints for non-btree indexes
Date
Msg-id 20060118163258.GE27070@svana.org
Whole thread Raw
In response to Re: Unique constraints for non-btree indexes  ("Jonah H. Harris" <jonah.harris@gmail.com>)
Responses Re: Unique constraints for non-btree indexes  ("Jonah H. Harris" <jonah.harris@gmail.com>)
Re: Unique constraints for non-btree indexes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Jan 18, 2006 at 09:15:04AM -0500, Jonah H. Harris wrote:
> I thought gistinsert had checkUnique, it was just ifdef'd out because there
> was no code to enforce it... and as such, during bootstrap it was marked as
> amcanunique = false.  Would it be that hard to enable it?

Well, it has the argument to gistinsert but it is commented out and
there is no other reference to unique anywhere in the GiST code. Once
the support infrastructure is there we can talk about enabling it. At
the very least we need to decide how to indicate what "unique" is.

For example: saying the two ranges (1,3) and (2,4) cannot co-exist in
the same index is not really what most people would consider the
behaviour of a "unique" index. Indeed, for any particular data-type,
there may be multiple ways of defining a conflict. For 2-D objects it
may refer to having no objects overlap, but it could also refer to no
overlaps in the X or Y axes.

I guess what you're talking about is a constrained index, of which a
unique index is just a particular type. I suppose the actual constraint
would be one of the operators defined for the operator class (since
whatever the test is, it needs to be indexable). Although some would
obviously be more useful than others...

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Bad estimate on LIKE matching
Next
From: "Jonah H. Harris"
Date:
Subject: Re: Unique constraints for non-btree indexes