Re: operator exclusion constraints [was: generalized index constraints]

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: operator exclusion constraints [was: generalized index constraints]
Date: 2009-09-20 23:42:26
Message-ID: 28439.1253490146@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jeff Davis <pgsql(at)j-davis(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2009-09-21 00:21:51 Re: operator exclusion constraints [was: generalized index constraints]
Previous Message Jeff Davis 2009-09-20 23:09:43 Re: operator exclusion constraints [was: generalized index constraints]