Hi, Keith, On Sat, Apr 23, 2016 at 5:56 AM, Keith Medcalf <kmedcalf at dessus.com> wrote: >> > What you are seeing there is SQLite just repeating back the type that >> the CREATE TABLE command used. It is not the type of data SQLite is >> actually storing. > >> > There is no 'varchar' datatype in SQLite. And it never truncates >> strings. > >> > I think that the best thing for you may be to read this page > >> > <https://www.sqlite.org/datatype3.html> > >> I know SQLite goes by the affinity and not by the type. Something like >> scripting language - nothing is typed. > > No SQLite does not "go by" the affinity or anything else, nor is "nothing is > typed". Everything is typed and is quite ducky, thank-you. (If you do not > understand, look up ducky typing). The only enforced type is that INTEGER > PRIMARY KEY (rowid) must be an integer. Other than that, all types are quite > ducky, and the affinity is merely a suggestion as to the colour to paint the > duck, if possible, before storing it away.
One good exmple will be: try to compare Pascal, C, C++, Java with Python, Perl, Ruby, etc... While former has strict types for all variables, the latter does not. You don't even have to declare a variable prior to use. (I hope you do know more languages, than just SQL. ;-) ). This was what I was pointing to. > >> However, what I'm saying is that most DBMS out there do store the size >> of the field. > > then maybe you want to use one of those? You don't know anything about the software trying to writre - so how can you propose a solution? > >> Even though I issue something like: >> >> CREATE TABLE test( id INTEGER, PRIMARY KEY, test1 VARCHAR(25), test2 >> INTEGER(3), test3 FLOAT(25,2) ); >> >> if I ask for the columns information, I will get: >> >> id INTEGER >> test1 VARCHAR 25 0 >> test2 INTEGER 3 0 >> test2 FLOAT 25 2 >> >> So instead of me parsing this info, it can be parsed by SQLite engine. > > In SQLite you get the above? Pray tell, how? No, that is the problem. I'm NOT getting this info. This information is given by, e.g. MS SQL Server (just an example). Unfortunately you removed the explanation of what is produced by SQLite. ;-) > >> I understand that for the reason of backward compatibility it will not >> be changed, >> but it may be something to consider for the next major release (SQLite4). > > I do not think it has anything to do with backward compatibility. It has to > do with something called design. The design of SQLite does not do the things > those other DBMSes of which you speak do, because it was DESIGNED not too. > Those things that those other DBMSes do are holdovers to maintain backwards > compatibility with the good old days when dinosaurs ruled the earth, 1KB of > RAM was an earth-shattering amount of memory (and cost more than six dozen > modern "coders" will earn in their lifetimes). SQLite is not backwards > compatible with those dinosaurs (though it will certainly run on their > descendants, which now are quite feisty, run quite quickly, and have memory > measured in GB or TB. SQLite started with bitty-boxen already ruling the > earth and therefore does not have to maintain the same backwards > compatibility as your other DBMSes. [rant start] Well, you don't have to give me all this. I merely tried to ask why in SQLite one can't have an information about the table field size - that is all. Whether it is for historical reasons, to maintain backward compatibility, because the author of SQLite designed the engine this way - this is what I'm after. Because all those reasons will help me better understand why SQLite differes from, e.g. ODBC. I also want to say that as user of the engine I can ask question and provide the suggestions. This is what the open-source is for. Whether the suggestion is good or bad, whether it will be implemented or not is up to the core devs/maintainters. I also believe that you can do the same and your suggestion and question can also be eiter approved or rejected and the question answered in a polite and understandable way. If people don't understand the question they come back and ask for more info or provide a reference, like Simon. [/rant end] Thank you. > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
