EzTools Support wrote: > I'm just wondering why I have not received any comment regarding this > issue...? > > EzTools Support wrote: > >> Hello DRH. This is further to the previous query regarding no type >> information being returned with Views. I had previously asked if >> this could be added, but have not received any comment. >> >> I'm sure anyone would agree that getting the column type data type >> back with views is no less important than getting it back with >> SELECTs. Why would it be? I need type info for any row-returning SQL >> command, be if from directly via SELECTs or indirectly from Views. >> Until this is fixed, I must tell my 3.0 customers they can't use >> Views :-(
I agree. Views should behave the same as real tables where ever possible. If selects on tables return type information, then selects on views should also return type info. >From your previous posts it looks like you are using the sqlite3_column_decltype function to get this info, but that is probably not correct. The sqlite3_column_type function should be used to get the type information for a column in a result set. It returns the type of the data actually being returned in that column. The function sqlite3_column_decltype is used to get the declaration type for a result column. This really only applies to result columns that are retrieved directly from a table column. What is the declaration type of the output of a function such as max(), count(), or like(), or the result of an expression using operators such as || or a relational operator like <? I think it makes sense for these columns to return a null value for the declaration type. It might be argued that each function and operator should define a result type value that could be returned as the declaration type for its output values. But that is not implemented now. The output of a view is similarly disconnected from the tables and functions it is based on by the select statement used to define the view. Again you could argue that view result columns based directly on a table column should return the declared type of that table column. I agree that that might be nice, but I don't think it is a critical omission. I believe the current implementation is based on the idea that views don't contain any column declarations, therefore they don't have any declaration types. I think your other point about the table names not being handled the same way is incorrect. If I create a simple table and view; create table t (a, b); create view v as select * from t; and then do several select statements as show below select * from t; select * from v; select t.a, t.b from t; select v.a, v.b from v; I get the same behavior in both cases. I think that you are expecting to create the view using table names like this create view v2 as select t.a, t.b from t; and then do a simple select select * from v2; and have result columns with tables names from the underlying table. That would be incorrect. What would you expect as result column names for the following query? select v2.a, v2.b from v2; I believe you are looking at views as standins for select statements, when thay are better though of as a slightly different kind of table. You should be able to do most of the same things with views that you can do with tables. Most differences arise because views don't actually store their rows; you can't create an index on a view for example.
