You're right Darren, but the problem is that we're not in a DB class. We cannot tell people who have a solution for their problems that "your solution is wrong. You need to reimplement your stuff to make it right". Most of SQLite users are practical people, and all they want is their problem to be solved. They don't really care if the SQL language is implementing correctly relational algebra or not.
-----Original Message----- From: Darren Duncan [mailto:[EMAIL PROTECTED] Sent: Friday, March 10, 2006 11:21 PM To: sqlite-users@sqlite.org Cc: [EMAIL PROTECTED] Subject: Re: [sqlite] updating SQLite to implement The Third Manifesto At 6:52 PM -0800 3/10/06, Roger Binns wrote: >Only for some applications. It would be harder to use for >my apps. Specifically manifest typing as currently implemented >in SQLite is a perfect match for apps writen in Python (which >also uses manifest typing). It would require a lot more code >to go through and force the data type for each column. If that is so, then I would argue that any need to write more code isn't tied to manifest typed programming languages themselves, but specific programs themselves; depending on how you code your applications, it wouldn't require any significant amount more code. In fact, particularly for queries (and reading data tends to be more common than writing), there should be less code. Or, looking at this another way, perhaps the Python bindings for SQLite should be taking care of this for you. Or, put another way, I would say this is a small price to pay for what is gained. Or, I doubt there actually is more work. (But I don't really want to get into an argument on this point, as there are many other points in my proposal which I see as being of greater importance.) But regardless, I have an additional idea which may help bridge the gap and work well for people. That is, while the database itself is strongly typed, you can have a specific type which is defined to manifestly be able to store values from any of a variety of simpler types. So for example, SQLite could have these types: - Boolean - Integer - Real - Text - Blob - Scalar The first 5 are simple types that store just numbers or text or whatever. The last, new 1, Scalar, is an actually-strong type which is defined as being able to store any of the first 5 types (just one at a time), and hence acts like a weak type. In a conceptual sense, a Scalar value is like a composite type with 6 member elements, each of the last 5 being strongly typed as one of the first 5 simple types, and the first element being an enum which says which of the other 5 holds the over-all current value. I believe something like this is what manifestly typed languages actually do behind the scenes, having a multi-element struct where one element says how to treat the other one(s). I know Perl does this, with its SV C-struct, and I'm sure other languages do similar. I know SQLite does something similar, if you look at its design spec. (Sure, that sounds more complicated, but then the actual work being done to support manifest typing *is* more complicated. Things look more like they are.) So if SQLite does it this way, then you can declare columns to be the Scalar type when you want them to hold anything, and one of the other types if you don't. Moreover, the effectively manifest typed Scalar is what you would get if you don't explicitly declare a type for a column. This happens already, but now the "what you get" actually has a name. The point is that you still get well defined behaviour that is specific to the declared data type(s) you choose to use, and you can count on its being consistent. -- Darren Duncan
