Re: operator exclusion constraints [was: generalized index constraints] - Mailing list pgsql-hackers

From Tom Lane
Subject Re: operator exclusion constraints [was: generalized index constraints]
Date
Msg-id 28439.1253490146@sss.pgh.pa.us
Whole thread Raw
In response to Re: operator exclusion constraints [was: generalized index constraints]  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: operator exclusion constraints [was: generalized index constraints]
Re: operator exclusion constraints [was: generalized index constraints]
List pgsql-hackers
Jeff Davis <pgsql@j-davis.com> writes:
> I suppose I should just allow any index_elem. The only way I was able to
> make the grammar for that work is by using a reserved keyword. The
> possibilities that make the most sense to me are:

>   index_elem WITH any_operator
>   index_elem WITH OPERATOR any_operator
>   index_elem CHECK any_operator
>   index_elem CHECK OPERATOR any_operator

> Do any of these look acceptable?

I'd vote for "CHECK", out of that list.  WITH has no mnemonic value
whatever.

I'm not that thrilled with CHECK either, mainly because it seems like
it ought to check that the operator condition *does* hold, whereas
you're going to check that it *doesn't* hold.  But perhaps the EXCLUSION
up front will be enough to set people straight.

BTW, are you sure EXCLUSION doesn't have to become a reserved word for
this?  I notice that FOREIGN, CHECK, and UNIQUE all are, which makes me
suspicious ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: operator exclusion constraints [was: generalized index constraints]
Next
From: Jeff Davis
Date:
Subject: Re: operator exclusion constraints [was: generalized index constraints]