Documentation Source Text

  global nChng aChng xrefChng
  set aChng($nChng) [list $date $desc $options]
  set xrefChng($date) $nChng
  incr nChng
}

chng {2019-07-00 (3.29.0)} {







<li> Improved optimization of AND and OR operators when one or the other
     operand is a constant.
<li> Added the "[https://sqlite.org/src/file/ext/misc/dbdata.c|sqlite_dbdata]"
     virtual table for extracting raw low-level content from an SQLite database,
     even a database that is corrupt.
<li> Enhancements to the [CLI]:
<ol type="a">
<li> Add the ".recover" command which tries to recover as much content
     as possible from a corrupt database file.
<li> Add the ".filectrl" command useful for testing.
<li> Add the long-standing ".testctrl" command to the ".help" menu.

</ol>
}

chng {2019-04-16 (3.28.0)} {
<li> Enhanced [window functions]:
<ol type="a">
<li> Add support the [EXCLUDE clause].

  global nChng aChng xrefChng
  set aChng($nChng) [list $date $desc $options]
  set xrefChng($date) $nChng
  incr nChng
}

chng {2019-07-00 (3.29.0)} {
<li> The [double-quoted string literal] misfeature is deactivated by default
     for DDL statements.  It can be reactivated if needed, to support legacy
     applications, using the [SQLITE_DBCONFIG_DQS_DDL] action of the
     [sqlite3_db_config()] interface.
<li> Added the [SQLITE_DBCONFIG_DQS_DML] action to [sqlite3_db_config()] that
     will disable the [double-quoted string literal] misfeature for DML
     statements.
<li> Improved optimization of AND and OR operators when one or the other
     operand is a constant.
<li> Added the "[https://sqlite.org/src/file/ext/misc/dbdata.c|sqlite_dbdata]"
     virtual table for extracting raw low-level content from an SQLite database,
     even a database that is corrupt.
<li> Enhancements to the [CLI]:
<ol type="a">
<li> Add the ".recover" command which tries to recover as much content
     as possible from a corrupt database file.
<li> Add the ".filectrl" command useful for testing.
<li> Add the long-standing ".testctrl" command to the ".help" menu.
<li> Added the ".dbconfig" command
</ol>
}

chng {2019-04-16 (3.28.0)} {
<li> Enhanced [window functions]:
<ol type="a">
<li> Add support the [EXCLUDE clause].

and single-quotes around string literals.  For example:
<ul>
<li> <tt>"this is a legal SQL column name"</tt>
<li> <tt>'this is an SQL string literal'</tt>
</ul>
<p>
SQLite accepts both of the above.  But, in an effort to be compatible
with MySQL 3.x (which was probably the most widely used RDBMS
when SQLite was first being designed) SQLite will also use
a double-quotes string as
string literal if it does not match any valid identifier.
<p>
This misfeature means that a misspelled double-quoted
identifier will be interpreted as a string literal, rather than generating
an error.
It also lures developers who are new to the SQL language into
................................................................................
string literals inside of DDL statements ([CREATE TABLE], [CREATE INDEX],
and so forth) is disallowed and will cause a syntax error.  Double quoted
strings needed to be deactivated in DDL statements as they were causing
problems for [ALTER TABLE].
(See the ticket at [https://www.sqlite.org/src/info/9b78184be266f] for
details.)
If needed for compatibility, the older behavior can be restored by 
disabling the [SQLITE_DBCONFIG_NO_DQS_SCHEMA] option on the
[sqlite3_db_config()] interface.
<li><p> The [SQLITE_DBCONFIG_NO_DQS] option the [sqlite3_db_config()]
interface is available as of SQLite 3.29.0 ([dateof:3.29.0]) and can be
used to disable double-quoted string literals in all contexts.
This setting is currently off by default, but might default on in future
releases of SQLite.  Developers are encouraged to turn this setting on
now, in preparation for the future when it might be activated by default.
</ul>

<h1>Keywords Can Often Be Used As Identifiers</h1>

and single-quotes around string literals.  For example:
<ul>
<li> <tt>"this is a legal SQL column name"</tt>
<li> <tt>'this is an SQL string literal'</tt>
</ul>
<p>
SQLite accepts both of the above.  But, in an effort to be compatible
with MySQL 3.x (which was one of the most widely used RDBMSes
when SQLite was first being designed) SQLite will also interpret
a double-quotes string as
string literal if it does not match any valid identifier.
<p>
This misfeature means that a misspelled double-quoted
identifier will be interpreted as a string literal, rather than generating
an error.
It also lures developers who are new to the SQL language into
................................................................................
string literals inside of DDL statements ([CREATE TABLE], [CREATE INDEX],
and so forth) is disallowed and will cause a syntax error.  Double quoted
strings needed to be deactivated in DDL statements as they were causing
problems for [ALTER TABLE].
(See the ticket at [https://www.sqlite.org/src/info/9b78184be266f] for
details.)
If needed for compatibility, the older behavior can be restored by 
disabling the [SQLITE_DBCONFIG_DQS_DDL] option on the
[sqlite3_db_config()] interface.
<li><p> The [SQLITE_DBCONFIG_DQS_DML] option the [sqlite3_db_config()]
interface is available as of SQLite 3.29.0 ([dateof:3.29.0]) and can be
used to disable double-quoted string literals for DML statements.
This setting is currently off by default, but might default on in future
releases of SQLite.  Developers are encouraged to turn this setting on
now, in preparation for the future when it might be activated by default.
</ul>

<h1>Keywords Can Often Be Used As Identifiers</h1>