On Sun, 2009-12-06 at 14:06 -0500, Tom Lane wrote:
> 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.
In ATAddOperatorExclusionConstraint():
tab->constraints = lappend(tab->constraints, newcon);
if that isn't done, it doesn't go into the code path with that error
message at all.
> 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.
Let's say someone is changing from box to a postgis geometry
representing a box. For boxes, "=" actually means "equal area" (aside:
this is insane); but for polygons, "=" mean "equal". Changing in the
other direction is bad, as well. I know operators mostly follow
convention most of the time, but I'm concerned with the subtle (and
surprising) differences.
But if someone is changing a column type, which causes a table rewrite,
hopefully they've planned it. I'll look into doing it as you suggest.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
