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@svana.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@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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDzm26IB7bNG8LQkwRAiUCAJ9MURp34CmKaxWFPrESKqvx2DDsYQCePSLv
JrKzcRQU7wf25oDv42Oeosc=
=y0WG
-----END PGP SIGNATURE-----
