On Sun, 2007-06-03 at 22:54 +0200, Alexander Staubo wrote: > I agree with you and I don't; as it stands now, it's too hard to > implement validation in the database alone, for the reasons I stated > earlier. But I would love for it to be possible, so that I can be sure > that not even plain SQL can screw up the data. You're blurring the line between an RDBMS and an application. Applications errors and database errors do not have a one-to-one mapping, although they do usually overlap. There are times when one database error maps onto several possible user-level errors; and when many database errors map onto the same user-level error; and when one database error does not cause any user-level error; and when something that is a user-level error might not have a matching constraint in the database at all. Trying to equate the two concepts is a bad idea. The application has much more information about the user and the context of the error that the database shouldn't have. For instance, the language that the user speaks might affect the error message. Or, there may be two possible user interface actions that result in the same constaint violation. For instance if you have a two-column unique constraint, perhaps there is one interface to change one column and one another. But you might want to return a different error to the user that makes sense in the context of which value they tried to change. A database error doesn't even always need to be propogated back to the user. If so, there would be no need for SAVEPOINTs and nobody would use ISOLATION LEVEL SERIALIZABLE (not directly related to constraints, but can cause an error just the same). Some user errors don't have a corresponding database constriant at all. For instance, how about a "re-type your password here" field? That should cause an error if it doesn't match the "password" field, but the database would have no matching constraint. Regards, Jeff Davis
