Re: operator exclusion constraints

On Thu, Nov 5, 2009 at 9:01 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> 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.

Ooh, that's kind of neat. But I think you'd need EXCLUSIVE (a, b) BY
(=, =), since it could equally well be EXCLUSIVE (a, b) BY (=, &&).

...Robert