Documentation Source Text

      <a href="http://www.sqlite.org/cvstrac/timeline">
      http://www.sqlite.org/cvstrac/timeline</a>.</p>
    }
    hd_close_aux
    hd_enable_main 1
  }
}






chng {2009 Jan 14 (3.6.9)} {
<li>Fix two bugs, which when combined might result in incorrect
    query results.  Both bugs were harmless by themselves; only when
    they team up do they cause problems.  Ticket #3581.
}

chng {2009 Jan 12 (3.6.8)} {
<li>Added support for [SAVEPOINT | nested transactions]</li>
<li>Enhanced the query optimizer so that it is able to use
    multiple indices to efficiently process 
    <a href="optoverview.html#or_opt">OR-connected constraints</a>

      <a href="http://www.sqlite.org/cvstrac/timeline">
      http://www.sqlite.org/cvstrac/timeline</a>.</p>
    }
    hd_close_aux
    hd_enable_main 1
  }
}

chng {2009 Jan 15 (3.6.10)} {
<li>Fix a cache coherency problem that could lead to database corruption.
    [Ticket #3584].
}

chng {2009 Jan 14 (3.6.9)} {
<li>Fix two bugs, which when combined might result in incorrect
    query results.  Both bugs were harmless by themselves; only when
    they team up do they cause problems.  [Ticket #3581].
}

chng {2009 Jan 12 (3.6.8)} {
<li>Added support for [SAVEPOINT | nested transactions]</li>
<li>Enhanced the query optimizer so that it is able to use
    multiple indices to efficiently process 
    <a href="optoverview.html#or_opt">OR-connected constraints</a>

</td>
<td width="20"></td><td bgcolor="#80a796" width="1"></td><td width="20"></td>
<td valign="top">
<h3>Current Status</h3>

<p><ul>
<li><a href="releaselog/3_6_9.html">Version 3.6.9</a>
of SQLite is recommended for all new development.  Upgrading from
versions 3.6.4 through 3.6.6.1 is strongly recommented.  Upgrading
from versions 3.6.6.2 or 3.6.7 is optional.  Upgrading from
version 3.6.8 is recommended.</li>
</ul></p>

<h3>Common Links</h3>

<p><ul>
<li> <a href="features.html">Features</a> </li>
<li> <a href="faq.html">Frequently Asked Questions</a> </li>

</td>
<td width="20"></td><td bgcolor="#80a796" width="1"></td><td width="20"></td>
<td valign="top">
<h3>Current Status</h3>

<p><ul>
<li><a href="releaselog/3_6_10.html">Version 3.6.10</a>
of SQLite is recommended for all new development.  Upgrading from
all prior versions is  recommented.</li>


</ul></p>

<h3>Common Links</h3>

<p><ul>
<li> <a href="features.html">Features</a> </li>
<li> <a href="faq.html">Frequently Asked Questions</a> </li>

  hd_puts "<h3>$date - $title</h3>"
  regsub -all "\n( *\n)+" $text "</p>\n\n<p>" txt
  regsub -all {[Tt]icket #(\d+)} $txt \
      {<a href="http://www.sqlite.org/cvstrac/tktview?tn=\1">\0</a>} txt
  hd_resolve "<p>$txt</p>"
  hd_puts "<hr width=\"50%\">"
}















































newsitem {2009-Jan-14} {Version 3.6.9} {
  Internal stress testing revealed a corner case where the cost function 
  on the query optimizer might mislead the query optimizer into making a 
  poor indexing choice.  That choice could then tickle another bug in 
  the VDBE which might result in an incorrect query result.  This
  release fixes both problems.  The chances of actually hitting this

  hd_puts "<h3>$date - $title</h3>"
  regsub -all "\n( *\n)+" $text "</p>\n\n<p>" txt
  regsub -all {[Tt]icket #(\d+)} $txt \
      {<a href="http://www.sqlite.org/cvstrac/tktview?tn=\1">\0</a>} txt
  hd_resolve "<p>$txt</p>"
  hd_puts "<hr width=\"50%\">"
}

newsitem {2009-Jan-15} {Version 3.6.10} {
  SQLite [version 3.6.10] fixes a cache coherency bug (Ticket #3584)
  introduced by check-in
  <a href="http://www.sqlite.org/cvstrac/chngview?cn=5864">[5864]</a>
  which was part of [version 3.6.5].  This bug might lead to database
  corruption, hence we felt it was important to get it out as quickly
  as possible, even though there had already been two prior releases
  this week.

  Some concern has been expressed that we are releasing too frequently.
  (Three releases in one week is a lot!)  The concern is that this creates
  the impression of volatility and unreliability.  We have been told that
  we should delay releases in order to create the impression of stability.
  But the SQLite developers feel that truth is more important than
  perception, not the other way around.  We think it is important to make
  the highest quality and most stable version of SQLite available to users
  at all times.  This week has seen two important bugs being discovered
  shortly after a major release, and so we have issued two emergency
  patch releases after the regularly scheduled major release.  This makes
  us look bad.  This puts "egg on our face."  We do not like that.  But, 
  three releases also ensures that the best quality SQLite code base
  is available available to you at all times.

  It has been suggested that "beta" releases might find these kinds of bugs
  prior to a major release.  But our experience indicates otherwise. 
  The two issues that prompted releases 3.6.9 and 3.6.10 were both
  discovered by internal testing and review - not by external users.
  And, indeed, most the problems found in SQLite these days are discovered
  by our rigorous <a href="testing.html">internal testing regimen</a>,
  not bug reports from the field.

  It has also been argued that we should withhold releases "until testing
  is finished."  The falacy there is that we never finish testing.  We
  are constantly writing new test cases for SQLite and thinking of new
  ways to stress and potentially break the code.  This is a continuous,
  never-ending, and on-going process.  All existing tests pass before each
  release.  But we will always be writing new tests the day after a release,
  regardless of how long we delay that release.  And sometimes those new
  tests will uncover new problems.

  All this is to say that we believe that SQLite version 3.6.10 is the
  most stable, most thoroughly tested, and bug-free version of SQLite
  that has ever existed.  Please do not be freaked out by three releases
  occurring in one week.
}

newsitem {2009-Jan-14} {Version 3.6.9} {
  Internal stress testing revealed a corner case where the cost function 
  on the query optimizer might mislead the query optimizer into making a 
  poor indexing choice.  That choice could then tickle another bug in 
  the VDBE which might result in an incorrect query result.  This
  release fixes both problems.  The chances of actually hitting this

HLR H18300 S20400
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_overload_function(sqlite3*, const char *zFuncName, int nArg);
</pre></blockquote>

HLR H18300 S20400
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_overload_function(sqlite3*, const char *zFuncName, int nArg);
</pre></blockquote>