Tuesday, November 1, 2005, 11:53:11 AM, [EMAIL PROTECTED] wrote: > Static typing in SQL is designed not to help the users of SQL > databases, but rather to help the implementors of SQL database > engines.
There are uses for static typing. Types in the SQL context can be used as a kind of integrity constraint. If my design calls for a measurement, say, in a REAL column, perhaps I don't want rows with text (e.g., "large") in this column. Types is a way to enforce this. > The difficult faced by SQLite is not how to deal with a dynamically > typed language (that's easy) but how to deal with a dynamic typing > in a way that is backwards compatible with the (broken) static typing > behavior of SQL. That is much harder. But it is achievable, I think. There is an ongoing debate on this subject at Lambda the Ultimate. One approach that is sound is to introduce a new static type, called DYNAMIC, that permits any value. Summarizing and seconding Dennis Cote's suggestion, perhaps columns that have no type declared, or that are declared DYNAMIC, behave as SQLite does today, and columns that have static declarations behave as if they are statically typed. Regards, e -- Doug Currie Londonderry, NH
