Re: operator exclusion constraints

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: operator exclusion constraints
Date: 2009-12-06 19:06:23
Message-ID: 29451.1260126383@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:
> Aha -- I think I see the problem you're having: if you try to rewrite
> one of the columns contained in the exclusion constraint, you get that
> error:

It fails for me regardless of which column is actually modified.
It could be this is a consequence of other changes I've been making,
but given the way ALTER TABLE works it's hard to see why the specific
column being modified would matter. Anything that forces a table
rewrite would lead to running through this code path.

I don't really agree with your argument that it's okay to reject the
case of altering the underlying column type, anyhow. There's enough
commonality of operator names that it's sensible to try to preserve
the constraint across a change. Consider replacing a circle with a
polygon, say. A no-overlap restriction is still sensible.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2009-12-06 19:24:34 Re: operator exclusion constraints
Previous Message Heikki Linnakangas 2009-12-06 18:35:39 Re: Summary and Plan for Hot Standby