Re: Translating constraints to RM Terms

>> And I in fact have a tentative answer, which is that they are,
>> respectively, the compile time and run time behavior of the
>> variables. (Alternatively, the static and dynamic behavior
>> of the variables.)
>
> I didn't know where you were going with this at first, but it is quite neat.
>
> But when you say compile time, are you speaking allegorically of the
> CREATE TABLE command?

Kinda. I can do it by looking at the create table command, because that has all the static data I need. (It contains the type data.)

In a language like, say C++, there is a clear and obvious distinction between compile time and runtime. In SQL, it is not at all obvious, for two reasons: you have the interactive use of the language, and you *untypechecked* use embedded in code. The distinction between compile time and runtime is obscured, because the two most common ways you use SQL have compile time and runtime always paired.

But consider: any *type constraint* can be checked without actually executing the query. Any non-type constraint cannot. If you give me a SQL insert, and the table definitions of the associated tables, I can tell you if the query is well-typed or not, but I cannot tell you if the constraints are met.

So if you have a table A with a single int column a, and you hand me "insert into A values ('hello, world')" I can reject this as mistyped immediately, *without reference to the current value of A.* This query is *always* wrong, because it is mistyped.

In contrast, if there's a foreign key constraint, and you hand me "insert into A values (1)" I cannot know whether this will pass constraints without examining the database. If your constraint involves invoking functions, I cannot know whether it will pass without actually executing the function.

Marshall Received on Tue Jun 07 2005 - 07:04:15 CEST