Обсуждение: Column 'CHECK' Constraint: bug or ?
It appears that Postgres checks column CHECK constraints when performing an update regardless of whether the particular column is being updated. Perhaps my understanding of column vs table constraints is incomplete but this doesn't seem to be proper behavior, and I can't find it documented anywhere. Can someone shed some light on this and whether I need to submit a bug report? PG v.7.0.3/Solaris-Sparc Keary Suska Esoteritech, Inc. "Leveraging Open Source for a better Internet"
Keary Suska <hierophant@pcisys.net> writes:
> It appears that Postgres checks column CHECK constraints when performing an
> update regardless of whether the particular column is being updated.
I believe that's true...
> Perhaps my understanding of column vs table constraints is incomplete
> but this doesn't seem to be proper behavior,
Why not? A constraint is a constraint, it should be valid whenever one
checks it.
regards, tom lane
On Wed, 19 Sep 2001, Keary Suska wrote: > It appears that Postgres checks column CHECK constraints when performing an > update regardless of whether the particular column is being updated. Perhaps > my understanding of column vs table constraints is incomplete but this > doesn't seem to be proper behavior, and I can't find it documented anywhere. If I read spec correctly, a column check constraint is equivalent to a table constraint of the same search condition (and name and attributes) for purposes of checking the constraint which means it should be valid at end of transaction/statement depending on the constraint attributes (and we don't support deferred check right now).
> From: Tom Lane <tgl@sss.pgh.pa.us> > Date: Thu, 20 Sep 2001 00:02:31 -0400 >> Perhaps my understanding of column vs table constraints is incomplete >> but this doesn't seem to be proper behavior, > > Why not? A constraint is a constraint, it should be valid whenever one > checks it. The question is, should Postgres be checking it at all? I suppose one only encounters this as a problem when they have a date-sensitive constraint (based on CURRENT_DATE). I can't imagine that this is an uncommon need. Of course, a trigger could be created to handle this, but it seems more straightforward to use a CHECK constraint, since that's what it is for, after all. Keary Suska Esoteritech, Inc. "Leveraging Open Source for a better Internet"