Re: [HACKERS] Unique constraints for non-btree indexes

On Wed, Jan 18, 2006 at 05:27:29PM -0500, Tom Lane wrote: > Right, the deadlock risk is exactly the reason you need some secret > sauce or other. Btree's page-level lock ensures that two insertions of > conflicting keys can't overlap (even if they ultimately get stored on > different pages). That

Re: [HACKERS] Unique constraints for non-btree indexes

Tom Lane <[EMAIL PROTECTED]> writes: > Martijn van Oosterhout writes: > > 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 > > w

Re: [HACKERS] Unique constraints for non-btree indexes

Martijn van Oosterhout writes: > On Wed, Jan 18, 2006 at 04:18:10PM -0500, Tom Lane wrote: >> In btree we can identify a unique page to lock for any given key value >> to ensure that no one else is concurrently inserting a conflicting >> key, thus usually allowing concurrent insertions of differen

Re: [HACKERS] Unique constraints for non-btree indexes

On Wed, Jan 18, 2006 at 04:18:10PM -0500, Tom Lane wrote: > I think the generalization that would be appropriate for GIST is that > a "unique" index guarantees there are no two entries x, y such that > x ~ y, where ~ is some boolean operator nominated by the opclass. We'd > probably have to insist

Re: [HACKERS] Unique constraints for non-btree indexes

On Wed, Jan 18, 2006 at 04:10:16PM -0500, Tom Lane wrote: > Martijn van Oosterhout writes: > > check_unique_index( ctid of inserting tuple, ctid of possibly > > conflicting tuple) > > I agree it's pretty ugly to have the index AM directly poking into > the heap, but adding a level of subroutine d

Re: [HACKERS] Unique constraints for non-btree indexes

Martijn van Oosterhout writes: > 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). A

Re: [HACKERS] Unique constraints for non-btree indexes

Martijn van Oosterhout writes: > check_unique_index( ctid of inserting tuple, ctid of possibly > conflicting tuple) I agree it's pretty ugly to have the index AM directly poking into the heap, but adding a level of subroutine doesn't really make that a whole lot nicer :-(. In any case, you've un

Re: [HACKERS] Unique constraints for non-btree indexes

I think I understand what you're saying, just that I don't think the btree index has anything to do with it.The extensibility is there for indexes to handle uniques in any way they choose.  If you wanted to add a common unique index checking function for GIST, I'd just add it to GIST.  It just seem

Re: [HACKERS] Unique constraints for non-btree indexes

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

Re: [HACKERS] Unique constraints for non-btree indexes

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?On 1/18/06, Martijn van Oosterhout wrote:Hi,Currently due to the way

[HACKERS] Unique constraints for non-btree indexes

Hi, Currently due to the way unique constraints are tied to btree there is no way to allow GiST indexes to do the same thing. The thing I'm specifically interested in is an index where you insert ranges (start,end) and if unique, the index will complain if they overlap. As a side-effect, this may