Re: operator exclusion constraints [was: generalized index constraints] - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: operator exclusion constraints [was: generalized index constraints]
Date
Msg-id 1255679812.15145.147.camel@jdavis
Whole thread Raw
In response to Re: operator exclusion constraints [was: generalized index constraints]  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: operator exclusion constraints [was: generalized index constraints]  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, 2009-09-20 at 17:54 -0400, Tom Lane wrote:
> (I'm wondering a bit if anyone will want a WHERE clause, too, though
> adding that later shouldn't pose any big syntactic obstacles.)

Where should I put the WHERE clause? My current syntax (with patch) is:

[ CONSTRAINT constraint_name ] EXCLUSION [USING index_method] (expression CHECK WITH operator [, ...]) index_parameters
}
[ DEFERRABLE | NOT DEFERRABLE ] [ INITIALLY DEFERRED | INITIALLY IMMEDIATE ]
[ WHERE predicate ]

That's a little awkward to document, because WHERE is only supported for
operator exclusion constraints, so it doesn't just fit along side CHECK
and FOREIGN KEY. My only concern is that it would make the CREATE TABLE
syntax slightly harder to read.

We could allow the WHERE clause to be syntactically correct for all the
other constraints, but throw a "not implemented" error if they try to
use it. I'm not sure if that fits nicely with the spec or not.

I tried to move the WHERE clause right before or after the
index_parameters, but that resulted in shift/reduce conflicts.

Thoughts?

Regards,Jeff Davis



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Hot standby, pausing recovery
Next
From: Simon Riggs
Date:
Subject: Re: inefficient use of relation extension?