Re: operator exclusion constraints

On Tue, 2009-11-03 at 08:51 -0800, Jeff Davis wrote:
> Peter, do any of these ideas work for you? It looks like this opens the
> door to using a word other than CHECK. CONSTRAIN NOT is a little
> awkward, is there another word that might work better?
>
> I'm not excited about using NOT, because I think it has a hint of a
> double-negative when combined with EXCLUSION. The original idea was to
> specify the way to find tuples mutually exclusive with the new tuple;
> and NOT makes that a little less clear, in my opinion. But I'm fine with
> it if that's what everyone else thinks is best.

I've been thinking how the other constraint types "read", e.g.,

a CHECK (a > 0) means "check that a is > 0"
b PRIMARY KEY means "b is the primary key"
c UNIQUE means "c is unique [in this table]"

That's easy. Whereas

EXCLUSION (a CHECK NOT =) means, er, "check that a is not an exclusion
of =" or something. Huh?

A more readable alternative might be going into the direction of
(written as a column constraint):

a EXCLUSIVE BY =

meaning "a is exclusive [in this table] [as measured] by =". Or as
table constraint

EXCLUSIVE (a, b) BY =

And then you could think of UNIQUE as "EXCLUSIVE BY default-equals-op".

EXCLUSIVE is already a key word, by the way.