Re: operator exclusion constraints
От | Jeff Davis |
---|---|
Тема | Re: operator exclusion constraints |
Дата | |
Msg-id | 1260127474.19545.429.camel@jdavis обсуждение исходный текст |
Ответ на | Re: operator exclusion constraints (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: operator exclusion constraints
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: