>> I think Nathan's point is that the integer you get when declaring a >> column INTEGER PRIMARY KEY can hold a 64-bit value anyway, so why >> couldn't it simply be declared differently and behave the same? > > INTEGER PRIMARY KEY is the exception to the rules for SQLite > datatypes. Any other column can hold any datatype, regardless of the > declared datatype. But an INTEGER PRIMARY KEY is different. INTEGER > PRIMARY KEY is an alias for the underlying rowid. It can only hold an > integer.
I don't think the question here is data types - I think it's data type sizes. If the answer to "why are types allowed in the DDL if SQLite ignores them" is "for the sake of application developers", then I would argue that in the situation where a particular type is required that that type be as unambiguous as possible. Just what defines "integer" varies by platform, compiler, language, database... etc. etc. Sometimes it's 32 bits, sometimes if 64, I even once worked on a platform where it meant unsigned 32 bit integer and signed ints had to be declared explicitly. If the docs said "PKs have to be INTEGERs, and INTEGERs are signed 64 bit whole-number values" then there could be no confusion. :) All that said I don't think this is worth changing... I was just curious. -T _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
