Re: operator exclusion constraints
От | Simon Riggs |
---|---|
Тема | Re: operator exclusion constraints |
Дата | |
Msg-id | 1257115335.9009.1051.camel@ebony обсуждение исходный текст |
Ответ на | Re: operator exclusion constraints (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: operator exclusion constraints
Re: operator exclusion constraints Re: operator exclusion constraints Re: operator exclusion constraints |
Список | pgsql-hackers |
On Sun, 2009-11-01 at 10:53 -0800, Jeff Davis wrote: > New patch attached. After reading the docs in the patch I don't believe you're going to all this trouble to ensure two circles don't overlap. Can you give some better examples of what you're trying to achieve and why anyone else would care? (I'm busy, so are others). I can probably guess, but my feeling is I shouldn't have to. I feel like this might be a truly great feature, but I'm worried that either it isn't at all or it is and yet will be overlooked. Does this project link in with other planned developments in various plugins? The current patch writes the syntax like this EXCLUSION USING gist (c CHECK WITH &&) makes it look like a table constraint, yet it clearly refers to a single column. That looks very clumsy to read, to my eyes. The syntax be easier to read if it was stated as a comparison e.g. in the circle example CHECK ( NOT (NEW.c && c)) USING GIST where NEW is the incoming row. This is similar to the way I would write the constraint if I wanted to ensure the values in two columns did not match/overlap etc CHECK ( NOT (col1 && col2)) and is also not such a radical departure from existing SQL Standard syntax. We only need the NOT when there isn't a clear negator defined, so in most cases I would hope to read something like this CHECK (NEW.pkey != pkey) USING btree which should be equivalent to the UNIQUE constraint I don't think its too late to change the syntax. -- Simon Riggs www.2ndQuadrant.com
В списке pgsql-hackers по дате отправления: