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. 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". > > From my point of view, this is not actually a knock-out-criterium, because: > > a) Existing applications would always continue to work, even if using newer > versions of sqlite.dll as it should be no problem for any later version that > intruduced feature X to continue using any database regardless of whether or > not this database actually contains feature X. (This is actual *backward* > compatibility.)
The issue for something like a data-time field is how would you indicate that a field is a data-time field. Due to backwards compatibility it can't use the term data or time to trigger that use, as existing applications use that and expect a different result, based on published and promised rules. > > b) New applications could decide whether or not to make use of any new > feature. > > c) Of course, an existing application doesn't know how to handle database > structures with feature X when using an sqlite.dll from the time before this > feature has been introduced. (I would, however, call this *forward* > compatibility.) This is true, but on the other hand, one might ask why an > arbitrary application actually might want to do this? I have often gotten the > response that it is up to the app how to handle data when reading from a > database (IIRC, DATE as a matter of fact was the topic of the discussion). So > one could as well argue that it is the app's responsibility to use up-to-date > libraries when accessing databases. (Note that this applies *only* to an app > dealing with *foreign* databases where one anyhow needs to know how to > interpret data, so this is no knock-out-problem.) > > Someone recently posted about SQLite support for the next 31 (or so) years. > Actually I hope this doesn't mean we will have to wait for three decades > until new features could be implemented...?! New features can, and have, been added. The key is that they need to use syntax that previously was an error (or at least without defined meaning) to implement it. > > Maybe a new subpage could be added to the website, named "proposed features" > or similar, just listing what has been proposed including some short > description. There have been many great ideas and it would be a pity if they > got lost in the depths of the mailing list ;) > > Just my 2cts > Thomas -- Richard Damon _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
