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: 27088.1253483698@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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
INCLUDING CONSTRAINTS EXCLUDING INDEXES would have failure cases.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

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