Skip site navigation (1) Skip section navigation (2)

Re: operator exclusion constraints [was: generalized index constraints]

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: operator exclusion constraints [was: generalized index constraints]
Date: 2009-09-20 21:54:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> 1. Constraint syntax, part of CREATE/ALTER TABLE:

>   [CONSTRAINT <name>] EXCLUSION (<expr> OPERATOR <op>, ...)

Have you actually built this grammar?  I don't think it avoids the
problem, because OPERATOR is possible within a_expr.

Also, don't forget the possibility of wanting a nondefault opclass.
(I'm wondering a bit if anyone will want a WHERE clause, too, though
adding that later shouldn't pose any big syntactic obstacles.)

> Brendan made a strong argument[15] that the behavior of LIKE
> with UNIQUE is wrong, but I don't know if we want to try to fix that
> now. I'd like some more input before I actually take care of this item.

That's really a separate issue, but I think we need to do something to
make it more consistent.  My first thought is that anything made
via CONSTRAINT syntax ought to be copied by LIKE INCLUDING CONSTRAINTS,
while LIKE INCLUDING INDEXES should copy anything you made via CREATE
INDEX.  But note this assumes that there is a clear distinction between
the two.  The constraint-depending-on-index design that you started
with would not permit such a rule, or at least it would mean that

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2009-09-20 21:58:03
Subject: Re: generic copy options
Previous:From: Jeff DavisDate: 2009-09-20 21:33:57
Subject: operator exclusion constraints [was: generalized index constraints]

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group