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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: operator exclusion constraints [was: generalized index constraints]
Дата
Msg-id 28439.1253490146@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: operator exclusion constraints [was: generalized index constraints]  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: operator exclusion constraints [was: generalized index constraints]  (Jeff Davis <pgsql@j-davis.com>)
Re: operator exclusion constraints [was: generalized index constraints]  (Peter Eisentraut <peter_e@gmx.net>)
Список 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 по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: operator exclusion constraints [was: generalized index constraints]
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: operator exclusion constraints [was: generalized index constraints]