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 17:12:30 |
Message-ID: | 36e682920601180912n3f956421t6e5011e133e24dae@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 seems to me like the access methods
should keep the handling internal to themselves.
On the chance that I'm not be understanding what you're saying, sorry.
On 1/18/06, Martijn van Oosterhout <kleptog(at)svana(dot)org> wrote:
>
> 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(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)
>
> iD8DBQFDzm26IB7bNG8LQkwRAiUCAJ9MURp34CmKaxWFPrESKqvx2DDsYQCePSLv
> JrKzcRQU7wf25oDv42Oeosc=
> =y0WG
> -----END PGP SIGNATURE-----
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-01-18 17:45:29 | Re: debug_query_string and multiple statements |
Previous Message | Martijn van Oosterhout | 2006-01-18 16:32:58 | Re: Unique constraints for non-btree indexes |