Column 'CHECK' Constraint: bug or ?

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"