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> 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} \
                 {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.
Not all of these compile-time options are usable by every application.
For example, the SQLITE_THREADSAFE=0 option is only usable by applications
that never access SQLite from more than one thread at a time.  And the
SQLITE_OMIT_PROGRESS_CALLBACK option is only usable by applications that
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>


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.