sqlite - Proposed Incompatible Changes

Not logged in

• Honeypot
• Browse
• Home
• Login
• Reports
• Search
• Ticket
• Timeline
• Wiki

• Contents
• Diff
• Text

There have been some suggestions for worthwhile changes to SQLite which we cannot do without breaking backwards compatibility. We normally work very hard to avoid imcompatibilities. But in cases where the compatibility break is very minor and likely to have minimal impact and where the change seems especially worthy, we will consider them.

This page accumulates proposed changes to SQLite that, while technically not 100% backwards compatible, only present very minor changes but offer substantial benefits. We put the proposals here so that they can accumulate and so we will not forget the next time we do an incompatible release. And, by putting the proposals here, we provide users an opportunity to complain if a proposed change would seriously inconvenience them in ways that we have not anticipated.

Support A DATE Type

Change SQLite so that it understands a new fundamental type for dates. There are two spare typecodes left - this would use one. Dates would be stored as 64-bit floating point values - the julian day number.

The incompatibility arises from the fact that a table column with a declared type of DATE would now undergo type coercion whereas formerly it would. This might lead to subtle problems in programs that currently use columns of this type.

The DATE type would only work on new databases. Legacy databases would continue to exhibit the legacy behavior. Older versions of SQLite would not be able to read or write databases that used the new DATE type.