From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: operator exclusion constraints |
Date: | 2009-11-01 22:42:15 |
Message-ID: | 1257115335.9009.1051.camel@ebony |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Boley | 2009-11-01 23:06:43 | Re: operator exclusion constraints |
Previous Message | Jeff Davis | 2009-11-01 18:53:20 | Re: operator exclusion constraints |