Re: Unique constraints for non-btree indexes

From: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Unique constraints for non-btree indexes
Date: 2006-01-18 14:15:04
Message-ID: 36e682920601180615o7dede534ia337ab2cfcfc9652@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 <kleptog(at)svana(dot)org> wrote:
>
> 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 make progress toward the goal of deferrable
> unique indexes.
>
> Part of the solution is to remove the layering violation from the btree
> code, it really shouldn't be accessing the heap directly. What I'm
> proposing is to move the bulk of _bt_check_unique into a new function
> (say check_unique_index) in the general index machinary and have the
> b-tree code do just:
>
> check_unique_index( ctid of inserting tuple, ctid of possibly conflicting
> tuple)
>
> The point being that GiST indexes could use exactly the same function
> to check for duplicates. The function would return InvalidTransactionId
> if there's no conflict, or an actual transaction id to wait on, just
> like the btree code does now.
>
> It would require some changes to the GiST code since a lot more of the
> index may need to be checked for duplicates. I suppose in the general
> case, since a key can appear in multiple places, the concurrency issues
> could be difficult. I suppose you would insert your key first, then
> check for duplicates thus ensuring that at least one of the two
> conflicting transactions will see it.
>
> Now, one side-effect is that you could build deferrable unique
> constraints on top of this by having the check function always return
> InvalidTransactionId but storing the conflicts for later checking. But
> I first want to know if there are any real issues with the above.
>
> Any thoughts?
> --
> Martijn van Oosterhout <kleptog(at)svana(dot)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.
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQFDzkmWIB7bNG8LQkwRArgRAJ9E34krswmsSEsMv6h/1d1KJc7crACgg1kp
> m32u4QtjXCqd53fjUP6WKUE=
> =E0+I
> -----END PGP SIGNATURE-----
>
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2006-01-18 14:53:54 Re: Surrogate keys (Was: enums)
Previous Message Martijn van Oosterhout 2006-01-18 13:58:46 Unique constraints for non-btree indexes