On Tue, Sep 15, 2009 at 11:31:48AM -0700, Jeff Davis wrote:
> On Tue, 2009-09-15 at 13:48 -0400, Robert Haas wrote:
> > So it allows us to create constraints of the following form?
> >
> > For all A in the index, there exists no B in the index such that the
> > given operator (which must be a binary operator returning boolean)
> > holds of A and B.
>
> Yes. And it's slightly more complicated for multi-column constraints:
>
> For all tuples A in the index with attributes 1 to N, there exists no
> tuple B such that:
> A1 op1 B1 AND
> A2 op2 B2 AND
> ...
> AN op2 BN
>
> If all operators are "=", and the index implements searching on
> equality, it's semantically equivalent to a unique index.
Interesting :) I take it op1..opN (it's opN, not op2, right?) need to
commute?
> > These are certainly less common requirements than what you're
> > talking about here, and I don't think it's important to try to
> > support them - at least not at this point - but the word
> > "generalized" doesn't give me a clue that I won't be able to do
> > those things but I will be able to make an index that prevents my
> > users from handing out duplicate IP blocks.
>
> As far as the name goes, the best I've got so far are "index
> constraints" and "generalized index constraints". I'm happy to change
> the name if you have a reasonable suggestion.
Here's a couple:
* "generalized-uniqueness constraints" the hyphen disambiguates
* "operator-based constraints" A little math-ier, but talks about the API rather than details of the server
implementation.
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
