Re: operator exclusion constraints - Mailing list pgsql-hackers

From Tom Lane
Subject Re: operator exclusion constraints
Date
Msg-id 6379.1257185577@sss.pgh.pa.us
Whole thread Raw
In response to Re: operator exclusion constraints  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: operator exclusion constraints
List pgsql-hackers
Jeff Davis <pgsql@j-davis.com> writes:
> On Mon, 2009-11-02 at 08:25 +0000, Peter Eisentraut wrote:
>> I think the word CHECK should be avoided completely in this syntax, to
>> avoid confusion with CHECK constraints.

> This is an easy change. I don't have a strong opinion, so the only thing
> I can think to do is ask for a vote.

> Do you have a specific alternative in mind? How about just "WITH"?

I think we had that discussion already, and rejected using "WITH" by
itself because it was so totally devoid of suggestion of what it was
the system would do "with" the expression or operator.

If we don't want to introduce a new reserved word it's difficult to
find alternatives :-(.  One thing that just came to mind is that we
might be able to do something like
EXCLUSION (expr CHECK NOT operator)
orEXCLUSION (expr CONSTRAIN NOT operator)

I like the "NOT" here because "CHECK NOT =" seems to convey pretty
clearly what it is you are checking for.  Because NOT is reserved and
can't appear as a connective, I think that this approach might allow
a non-reserved leading word, thus possibly the second variant would
work without reserving CONSTRAIN.  I have not tested whether bison
agrees with me though ;-).  In any case I think "CHECK NOT =" reads
pretty well, and don't feel a strong urge to use some other word there.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Renaming conversion procs (was Re: [GENERAL] Error on compile for Windows)
Next
From: Heikki Linnakangas
Date:
Subject: Re: Architecture of walreceiver (Streaming Replication)