Subject | new & old context in CHECK constraints |
---|---|
Author | Marco Bommeljé |
Post date | 2002-11-13T17:45:19Z |
Hello everyone,
I want to share a nice, but undocumented, feature in Firebird (and
Interbase). Somehow, I am not sure whether or not I should use it.
Therefore, I am looking for some expert feed-back on its status (bug,
feature, will be documented, will disappear in time).
Suppose I want to extend the employee database to allow raising the
salary, but reject salary reductions. Such "transition" contraints are
usually programmed in TRIGGER code. But look at this CHECK constraint:
/* This works!! Let's consider it a feature. */
ALTER TABLE employee
ADD CONSTRAINT employee_salary_raise_ck
CHECK ((old.salary IS NULL) OR (new.salary >= old.salary));
Obviously, the nice thing is that "transition" constraints can be
defined declaratively.
So, what is the experts opinion?
Cheers,
Marco
I want to share a nice, but undocumented, feature in Firebird (and
Interbase). Somehow, I am not sure whether or not I should use it.
Therefore, I am looking for some expert feed-back on its status (bug,
feature, will be documented, will disappear in time).
Suppose I want to extend the employee database to allow raising the
salary, but reject salary reductions. Such "transition" contraints are
usually programmed in TRIGGER code. But look at this CHECK constraint:
/* This works!! Let's consider it a feature. */
ALTER TABLE employee
ADD CONSTRAINT employee_salary_raise_ck
CHECK ((old.salary IS NULL) OR (new.salary >= old.salary));
Obviously, the nice thing is that "transition" constraints can be
defined declaratively.
So, what is the experts opinion?
Cheers,
Marco