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> 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">

  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> Added the [SQLITE_DBCONFIG_DQS_DML] and [SQLITE_DBCONFIG_DQS_DDL]
     actions to [sqlite3_db_config()] for activating and deactivating
     the [double-quoted string literal] misfeature.  Both default to "on"
     for legacy compatibility, but developers are encouraged to turn them
     "off", perhaps using the [-DSQLITE_DQS=0] compile-time option.
<li> [-DSQLITE_DQS=0] is now a [recommended compile-time option].

<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">

    hd_keywords $all
  }
  hd_puts <p><b>$name</b></p>
  regsub -all "\n\\s*\n" $text "</p>\n\n<p>" text
  hd_resolve <blockquote><p>$text</p></blockquote>
}

hd_fragment rcmd {recommended compile-time options}

</tcl>

<h1>Recommended Compile-time Options</h1>

<p>The following compile-time options are recommended for applications that
are able to use them, in order to minimized the number of CPU cycles and
the bytes of memory used by SQLite.
................................................................................
doe not use the [sqlite3_progress_handler()] interface.  And so forth.

<p>It is impossible to test every possible combination of compile-time
options for SQLite.  But the following set of compile-time options is
one configuration that is always fully tested.

<ol>



<li><p><b>[SQLITE_THREADSAFE=0]</b>.
Setting -DSQLITE_THREADSAFE=0 causes all of the mutex and thread-safety logic
in SQLite to be omitted.  This is the single compile-time option that makes
the most difference in optimizing the performance of SQLite.

<li><p><b>[SQLITE_DEFAULT_MEMSTATUS=0]</b>.
This setting causes the [sqlite3_status()] interfaces that track memory usage
................................................................................
  This macro sets the default value for
  the [SQLITE_LIMIT_WORKER_THREADS] parameter.  The [SQLITE_LIMIT_WORKER_THREADS]
  parameter sets the maximum number of auxiliary threads that a single
  [prepared statement] will launch to assist it with a query.  If not specified,
  the default maximum is 0.
  The value set here cannot be more than [SQLITE_MAX_WORKER_THREADS].
}




















COMPILE_OPTION {SQLITE_EXTRA_DURABLE} {
  The SQLITE_EXTRA_DURABLE compile-time option that used to cause the default
  [PRAGMA synchronous] setting to be EXTRA, rather than FULL.  This option
  is no longer supported.  Use
  [SQLITE_DEFAULT_SYNCHRONOUS|SQLITE_DEFAULT_SYNCHRONOUS=3] instead.
}

    hd_keywords $all
  }
  hd_puts <p><b>$name</b></p>
  regsub -all "\n\\s*\n" $text "</p>\n\n<p>" text
  hd_resolve <blockquote><p>$text</p></blockquote>
}

hd_fragment rcmd {recommended compile-time options} \
                 {recommended compile-time option}
</tcl>

<h1>Recommended Compile-time Options</h1>

<p>The following compile-time options are recommended for applications that
are able to use them, in order to minimized the number of CPU cycles and
the bytes of memory used by SQLite.
................................................................................
doe not use the [sqlite3_progress_handler()] interface.  And so forth.

<p>It is impossible to test every possible combination of compile-time
options for SQLite.  But the following set of compile-time options is
one configuration that is always fully tested.

<ol>
<li><p><b>[SQLITE_DQS=0]</b>.
This setting disables the [double-quoted string literal] misfeature.

<li><p><b>[SQLITE_THREADSAFE=0]</b>.
Setting -DSQLITE_THREADSAFE=0 causes all of the mutex and thread-safety logic
in SQLite to be omitted.  This is the single compile-time option that makes
the most difference in optimizing the performance of SQLite.

<li><p><b>[SQLITE_DEFAULT_MEMSTATUS=0]</b>.
This setting causes the [sqlite3_status()] interfaces that track memory usage
................................................................................
  This macro sets the default value for
  the [SQLITE_LIMIT_WORKER_THREADS] parameter.  The [SQLITE_LIMIT_WORKER_THREADS]
  parameter sets the maximum number of auxiliary threads that a single
  [prepared statement] will launch to assist it with a query.  If not specified,
  the default maximum is 0.
  The value set here cannot be more than [SQLITE_MAX_WORKER_THREADS].
}

COMPILE_OPTION {SQLITE_DQS=<i>N</i>} {
  This macro determines the default values for
  [SQLITE_DBCONFIG_DQS_DDL] and [SQLITE_DBCONFIG_DQS_DML], which
  in turn how SQLite handles each [double-quoted string literal].
  The <i>N</i> argument should be an integer 0, 1, 2, or 3.
  <blockquote><table border=1 cellpadding="0" cellspacing="0">
  <tr><th rowspan="2">SQLITE_DQS<th colspan="2">Double-Quoted Strings Allowed
      <th rowspan="2">Remarks
  <tr><th>In DDL<th>In DML
  <tr><td>3<td>yes<td>yes<td>default
  <tr><td>2<td>yes<td>no<td>&nbsp;
  <tr><td>1<td>no<td>yes<td>&nbsp;
  <tr><td>0<td>no<td>no<td>recommended
  </table></blockquote>
  <p>The recommended setting is 0, meaning that double-quoted
  strings are disallowed in all contexts.  However, the default
  setting is 3 for maximum compatibility with legacy applications.
}

COMPILE_OPTION {SQLITE_EXTRA_DURABLE} {
  The SQLITE_EXTRA_DURABLE compile-time option that used to cause the default
  [PRAGMA synchronous] setting to be EXTRA, rather than FULL.  This option
  is no longer supported.  Use
  [SQLITE_DEFAULT_SYNCHRONOUS|SQLITE_DEFAULT_SYNCHRONOUS=3] instead.
}

<p>
In hindsight, we should not have tried to make SQLite accept MySQL 3.x
syntax, and should have never allowed double-quoted string literals.
However, there are countless applications that make use of
double-quoted string literals and so we continue to support
that capability to avoid breaking legacy.
<p>
Updates:
<ul>
<li><p> As of SQLite 3.27.0 ([dateof:3.27.0]) the use of a double-quoted
string literal causes a warning message to be sent to the [error log].
<li><p> As of SQLite 3.29.0 ([dateof:3.29.0]) the use of double-quoted
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>

<p>
The SQL language is rich in keywords.
Most SQL implementations do not allow keywords to be used as identifiers
(the names of table or columns) unless they are enclosed in double-quotes.

<p>
In hindsight, we should not have tried to make SQLite accept MySQL 3.x
syntax, and should have never allowed double-quoted string literals.
However, there are countless applications that make use of
double-quoted string literals and so we continue to support
that capability to avoid breaking legacy.
<p>
As of SQLite 3.27.0 ([dateof:3.27.0]) the use of a double-quoted
string literal causes a warning message to be sent to the [error log].
<p>
As of SQLite 3.29.0 ([dateof:3.29.0]) the use of double-quoted
string literals can be disabled at run-time using the
[SQLITE_DBCONFIG_DQS_DDL] and [SQLITE_DBCONFIG_DQS_DML] actions
to [sqlite3_db_config()].  The default settings can be altered
at compile-time using the [-DSQLITE_DQS=<i>N</i>] compile-time
option.  Application developers are encouranged to compile using
-DSQLITE_DQS=0 in order to disable the double-quoted string literal
misfeature by default.  If that is not possible, then disable
double-quoted string literals for individual database connections
using C-code like this:
<blockquote><pre>
sqlite3_db_config(db, SQLITE_DBCONFIG_DQS_DDL, 0, (void*)0);
sqlite3_db_config(db, SQLITE_DBCONFIG_DQS_DML, 0, (void*)0);
</pre></blockquote>
<p>Or, if double-quoted string literals are disabled by default, but need
to be selectively enabled for some historical database connections,
that can be done using the same C-code as shown above except with the
third parameter changed from 0 to 1.

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

<p>
The SQL language is rich in keywords.
Most SQL implementations do not allow keywords to be used as identifiers
(the names of table or columns) unless they are enclosed in double-quotes.