Re: operator exclusion constraints
От | Jeff Davis |
---|---|
Тема | Re: operator exclusion constraints |
Дата | |
Msg-id | 1257532975.27737.564.camel@jdavis обсуждение исходный текст |
Ответ на | Re: operator exclusion constraints ("David E. Wheeler" <david@kineticode.com>) |
Ответы |
Re: operator exclusion constraints
|
Список | pgsql-hackers |
Out of the ideas in this thread, here are the best and most complete so far: Form 1: WORD1 [ USING index_method ] ( expression WORD2 operator [, ... ] ) index_parameters [ WHERE ( predicate ) ] Form 2: WORD1 [ USING index_method ] ( expression [, ... ] ) WORD2 ( operator [, ...] ) index_parameters [ WHERE ( predicate) ] Word 1: EXCLUSION EXCLUDE Word 2: CHECK WITH BY (only works with Form 2) The current syntax is Form 1 using EXCLUSION/CHECK WITH. I had trouble making the grammar work using EXCLUDING or EXCLUSIVE. However, even if we get past that problem, we would want to move the "USING index_method" clause afterward (otherwise it's too awkward), but that causes conflicts with the index_parameters (because of the "USING INDEX TABLESPACE tablespace" clause). CHECK WITH has a little more meaning than BY, but as Peter says, it might cause confusion with a regular CHECK constraint. EXCLUDE implies that the thing on the right hand side is being excluded, when it's actually specifying what pairs of tuples are mutally exclusive; so I think EXCLUDE is a little bit too specific. Right now, I am leaning toward Form 2, and EXCLUSION/BY. So the typical case would read like: EXCLUSION USING gist (room, during) BY (=, &&) Comments, ideas or votes welcome. However, if anyone has any new ideas, please make an attempt to ensure that the grammar can work and that it's just as expressive. We've had several productive brainstorming sessions so far, and I certainly appreciate the input, but I think it's time to move toward a consensus. Regards,Jeff Davis
В списке pgsql-hackers по дате отправления: