Re: operator exclusion constraints

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

In response to

Responses

Browse pgsql-hackers by date

  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