9th April 15:15
If you don't want to compromise in the face of the halting problem, more
power to you but don't expect me to join you. Your desire to avoid
compromises will not make the halting problem go away. Regardless, I don't
see what is broken about computability theory.
I don't think you understood which theory I applied pragmatically.
Are you arguing in support of hidden constraints and hidden updates as good
enough even if not perfect?
I don't see what this has to do with whether the dbms must express to the
user every constraint that might affect a user prior to the user
encountering it at runtime. (ie. no hidden constraints)
I believe in more than one theory. I prefer not to ignore the halting problem.
You have just given your safety system the task of solving the halting problem.
Your absolute rejection won't change anything or solve the halting problem.
I know. While not the exact situation, I believe the following reference
deals with a similar problem:
One may come up with algorithms that transform some constraints such that
they no longer mention hidden relvars, but the general case is a hard
problem. In fact, I suspect it is fairly easy to prove that one cannot
describe some simple constraints without ******** reference to a specific
relvar. Even if the security function prevents one from spelling out the
constraint to a user, the dbms can still enforce it.
It is wrong to assume it was impossible for the manager to attempt to
violate any of the transition constraints on the basis of no attempt. He was
not able to see the other audit trail directly. He never tried to violate
any of the transition constraints the dbms enforced, which is the equivalent
of not looking.
I have thought about it. The example involves both hidden updates and hidden
constraints. If the manager violated a transition constraint that references
the relvars he manipulates and the relvars hidden from view, the dbms would
have to balk even though the security function prevents the dbms from
mentioning the hidden relvars.
The triggered procedures might force every transition to match the
constraint, or they might not. In general, the dbms won't be able to decide
whether this is the case; although, it might be able to decide some or even
most of the time.
Consider a situation where the dbms is upgraded and where the upgrade
includes an additional algorithm that would determine whether a specific
triggered procedure will guarantee a constraint.
On the basis of this algorithm, the dbms might conclude it does not need to
enforce a specific constraint because it now knows the data can never
violate it. (i.e. the dbms has a proof that the constraint always evaluates
to true for a specific update.) The dbms might run faster, but there is no
change in logical behaviour because the update never could violate the
constraint even when the dbms tested for it during the update.
Consider the situation with your 'safety system'. Prior to the upgrade, the
dbms lacks the ability to know whether to enforce the constraint and might
conclude it is too expensive to decide the matter. (ie. the dbms balks on a
specific update) After the upgrade, the dbms allows the update. The addition
of a new optimization algorithm should not change the logical behaviour of
The 'safety system' approach you propose above will cause the logical
behaviour to change even though the logic remains the same.