On Sunday, 11 August, 2019 16:02, Richard Damon <rich...@damon-family.org> wrote:
>On 8/11/19 4:21 PM, Thomas Kurz wrote: >>> I do understand the value of having date/time types in SQLite, but >>> it is not easy to do while retaining backward compatibility. I do not see any value in having a date/time type is SQLite. I do not see any value whatsoever that cannot be met by the existing datatypes (though an extensible type system would be nice, if I really want one of those I can use a database that has one, the only one I know of being DB2). What "value" would a built-in date/time type have? What possible utility could it provide that does not already exist? Even if one were to add one, it would be fraught with peril since it would undoubtedly be implemented badly. Almost all date/time types in almost every existing Operating System or language or database system is implemented badly and it would be far better off if this sort of thing did not exist at all because for almost all practical uses the "builtin" crap has to be ignored and re-written to operate properly. Or you have to incorporate massive amounts of code to work around the deficiencies. Then you have the crap Operating Systems that are inherently defective in their handling and concept of date/time (which are most of them). And you have to write your own code to do it properly anyway. And that sort of defeats the whole purpose of a lite embedded database engine if it has to be overloaded with a massive amount of code to handle date/time properly -- possibly duplicating at great expense what already exists elsewhere. For example, on *some* combinations of Operating System and Language you would have the same code to do "proper" date/time handling duplicated three times, once in the OS, once in the programming language standard library, and once in the database engine. Then of course every third-party library would also have its own duplicated code base to do the same thing. And that is assuming that everyone's definition of "properly" is the same (which it definitely will not be). >>> It'll have to wait for SQLite4 or something. >> Actually I do not really understand the point about backward >> compatibility. Many very useful suggestions are rejected by just >> citing "backward comatibility". As I said previously this is a non-issue unless one wants to add a new type to be dealt with internally (which is not needed). The table column datatype is an arbitrary string. You can put in there whatever you like and interpret it accordingly. Mutatis mutandis the column names returned from a select statement. So while it may be of some (questionable) value to add additional datatypes like decimal (decimal32/decimal64/decimal128 etc), different float widths (float16, float32, float64, float128 etc), or different integer types (int8, int16, int43, int64, int128 etc., and the unsigned varients) these do not provide a whole lot of additional value (though the decimalXX types might). An extensible arbitrary-type system would be more valuable. Since date/time is stored as an offset in some units from an epoch of some type, the "datatype" declaration is nothing more than an annotation of an already existing double or integer type -- and you can already annotate your select column names and table attribute type declarations just fine. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
