Puneet, Will and Kurt,
You all have very good points. While I agree partially with Will and Kurt, Puneet is definitely closer to my opinion.
I'm writing a tool to access *any* SQLite database. The problem is that the current introspection implementation in SQLite is incomplete. Yes, I agree that PRIMARY KEY is a constraint. But if SQLite treats INTEGER as the datatype and PRIMARY KEY as the constraint and does not provide support for both, we have a problem. Well, at least *I* have a problem ;-)
As Kurt very well suggested, one can concentrate the efforts in sqlite_master's SQL statement for a given table, but that is a dangerous proposition. IMHO, it's an implementation detail that should be supported by an API. If one day Dr. Hipp decides to improve the internals and decides to change the implementation, our code will break in an instant. This is not a good thing. With an API that distinguishes between datatype and its constraint, access to the internals will be guaranteed in a safely manner.
Is this issue being solved in SQLite 3.0?
Again, thank you all for your comments.
Best regards,
-- Tito
On 29 may 2004, at 10:55, Puneet Kishor wrote:
except, if you know something is INTERGER PRIMARY KEY, you know two things for certain -- that it is of type INTEGER, and that it is a PRIMARY KEY. The information is complete, albeit, more than what _you_ want. Otoh, if Tito sees something as INTEGER, he knows it is of type INTEGER, but he has no idea whether it is a PRIMARY KEY or not. The information is not complete as far as he is concerned.
It is a matter of debate whether PRIMARY KEY is a constraint or not. I would agree with you that it is a constraint, but then, arguably INTEGER is also a constraint because it constrains what kind of data can go into that column.
Since the CREATE statements allows one to specify a column type as INTEGER PRIMARY KEY, by context I would be more likely to consider it a column type than a column type + a constraint. I would treat a INTEGER DEFAULT (5) also as the complete information to figure out the default type.
I believe that folks designing applications of any sort (and, it would seem that most users of SQLite on this list are application designers rather than just managers of data that happen to reside in SQLite) have a continuing and real need to easily determine the column types. If these types happen to include "constraints" and "default values," great, we want to know those also. While the info in sqlite_master does give the "schema," it is arguably a tad inconvenient to get at. Now I have learned that various PRAGMAs allow me to do just that. So, they should do it completely.
Puneet,
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
