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]
Re: operator exclusion constraints [was: generalized index constraints] |
Список | 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 по дате отправления: