Re: operator exclusion constraints - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: operator exclusion constraints
Date
Msg-id 1257115335.9009.1051.camel@ebony
Whole thread Raw
In response to Re: operator exclusion constraints  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: operator exclusion constraints
Re: operator exclusion constraints
Re: operator exclusion constraints
Re: operator exclusion constraints
List 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 by date:

Previous
From: Jeff Davis
Date:
Subject: Re: operator exclusion constraints
Next
From: Nathan Boley
Date:
Subject: Re: operator exclusion constraints