Documentation Source Text

<li> <a href="chronology.html">Prior Releases</a>
<li> <a href="lang.html">SQL Syntax</a>
<ul>
<li> <a href="pragma.html#toc">Pragmas</a>
<li> <a href="lang_corefunc.html">SQL functions</a>
<li> <a href="lang_datefunc.html">Date &amp; time functions</a>
<li> <a href="lang_aggfunc.html">Aggregate functions</a>
<li> <a href="windowfunctions.html#biwinfunc">Window functions</a>
<li> <a href="json1.html">JSON functions</a>
</ul>
</li>
<li> <a href="c3ref/intro.html">C/C++ Interface Spec</a>
<ul>
<li> <a href="cintro.html">Introduction</a>
<li> <a href="c3ref/funclist.html">List of C-language APIs</a>

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

chng {2018-09-25 (3.25.2)} {
<li> Add the [PRAGMA legacy_alter_table=ON] command that causes the
     "ALTER TABLE RENAME" command to behave as it did in SQLite versions 3.24.0
     and earlier: references to the renamed table inside the bodies of triggers
     and views are not updated.  This new pragma provides a compatibility
     work around for older programs that expected the older, wonky behavior
     of ALTER TABLE RENAME.
<li> Fix a problem with the new [window functions] implementation that caused
     a malfunction when complicated expressions involving window functions were used
     inside of a view.
<li> Fixes for various other compiler warnings and minor problems associated
     with obscure configurations.
<p><b>Hashes:</b>
<li>SQLITE_SOURCE_ID: "2018-09-25 19:08:10 fb90e7189ae6d62e77ba3a308ca5d683f90bbe633cf681865365b8e92792d1c7"
<li>SHA3-256 for sqlite3.c: 34c23ff91631ae10354f8c9d62fd7d65732b3d7f3acfd0bbae31ff4a62fe28af
} {patchagainst 1 patchagainst 2}

chng {2018-09-18 (3.25.1)} {
<li> Extra sanity checking added to ALTER TABLE in the 3.25.0 release
     sometimes raises a false-positive
     when the table being modified has a trigger that
     updates a virtual table.  The false-positive caused the ALTER
     TABLE to rollback, thus leaving the schema unchanged.
     Ticket [https://sqlite.org/src/info/b41031ea2b537237|b41031ea2b537237].

#    ORDER BY mtime DESC;
#
# A small amount of manual editing and de-duplication followed.
#
# Manually edit the list for each subsequent release.
#      
foreach line [split {
fb90e7189a|2018-09-25|Version 3.25.2
2ac9003de4|2018-09-18|Version 3.25.1
b63af6c3bd|2018-09-15|Version 3.25.0
c7ee083322|2018-06-04|Version 3.24.0
4bb2294022|2018-04-10|Version 3.23.1
736b53f57f|2018-04-02|Version 3.23.0
0c55d17973|2018-01-22|Version 3.22.0
1a584e4999|2017-10-24|Version 3.21.0

[full-featured SQL|full-featured], [public-domain],
SQL database engine.
SQLite is the [most used] database engine in the world.
<a class="button" href="about.html">More Info</a></p>

<hr class="xhr">
<span class="hdrfont">Latest Release:&nbsp;&nbsp;</span>
<a href="releaselog/3_25_2.html">Version 3.25.2</a> ([dateof:3.25.2]).
<a class="button" href="download.html">Download</a>
<a class="button" href="chronology.html">Prior Releases</a>

<div class="mobileonly">
<hr class="xhr">
<h3>Common Links</h3>
<tcl>common_links</tcl>

<p>The boolean identifiers TRUE and FALSE are usually just aliases for
the integer values 1 and 0, respectively.  However, if TRUE or FALSE
occur on the right-hand side of an IS operator, then they form new
unary postfix operators "IS TRUE" and "IS FALSE" which test the boolean
value of the operand on the left.

<h3>Functions</h3>
<p>SQLite supports many [corefunc|simple], [aggfunc|aggregate],
and [window functions|window]
SQL functions.  For presentation purposes, simple functions are further
subdivided into [corefunc | core functions], [datefunc|date-time functions],
and [json1|JSON functions].
Applications can add new functions, written in C/C++, using the
[sqlite3_create_function()] interface.
</p>

<p>^It is possible to have an aggregate function with the same name as a
simple function, as long as the number of arguments for the two forms of the
function are different.  ^For example, the [agg_max|max()] function with a

  2 arguments.
}

funcdef {glob(X,Y)} {} {
  ^The glob(X,Y) function is equivalent to the
  expression "<b>Y GLOB X</b>".
  Note that the X and Y arguments are reversed in the glob() function
  relative to the infix [GLOB] operator.  Y is the string and X is the
  pattern.  So, for example, the following expressions are equivalent:
  <blockquote><pre>
     name LIKE '*helium*'
     glob('*helium*',name)
  </pre></blockquote>
  <p>^If the [sqlite3_create_function()] interface is used to
  override the glob(X,Y) function with an alternative implementation then
  the [GLOB] operator will invoke the alternative implementation.
}

funcdef {ifnull(X,Y)} {} {
  ^The ifnull() function returns a copy of its first non-NULL argument, or
  NULL if both arguments are NULL.  ^Ifnull() must have exactly 2 arguments.

funcdef {like(X,Y) like(X,Y,Z)} {} {
  ^The like() function is used to implement the
  "<b>Y LIKE X &#91;ESCAPE Z&#93;</b>" expression. 
  ^If the optional ESCAPE clause is present, then the
  like() function is invoked with three arguments.  ^Otherwise, it is
  invoked with two arguments only. Note that the X and Y parameters are
  reversed in the like() function relative to the infix [LIKE] operator.
  X is the pattern and Y is the string to match against that pattern.
  Hence, the following expressions are equivalent:
  <blockquote><pre>
     name LIKE '%neon%'
     like('%neon%',name)
  </pre></blockquote>
  ^The [sqlite3_create_function()] interface can be used to override the
  like() function and thereby change the operation of the
  [LIKE] operator.  When overriding the like() function, it may be important
  to override both the two and three argument versions of the like() 
  function. Otherwise, different code may be called to implement the
  [LIKE] operator depending on whether or not an ESCAPE clause was 
  specified.

  ^This SQL function is implemented using the [sqlite3_result_zeroblob()]
  routine from the C/C++ interface.
}
</tcl>

<p>The core functions shown below are available by default. 
[datefunc | Date &amp; Time functions],
[aggfunc | aggregate functions],
[builtin window functions|window functions], and
[json1 | JSON functions] are documented separately.  An
application may define additional
functions written in C and added to the database engine using
the [sqlite3_create_function()] API.</p>

<tcl>
set lx {}

so the date is normalized to 2001-05-01.  ^A similar effect occurs when
the original date is February 29 of a leapyear and the modifier is
&plusmn;N years where N is not a multiple of four.</p>

<p>^The "start of" modifiers (7 through 9) shift the date backwards 
to the beginning of the current month, year or day.</p>

<p>^The "weekday" modifier advances the date forward, if necessary,
to the next date where the weekday number is N. Sunday is 0, Monday is 1,
and so forth.
^If the date is already on the desired weekday, the "weekday" modifier
leaves the date unchanged.  </p>

<p>^The "unixepoch" modifier (11) only works if it immediately follows 
a timestring in the DDDDDDDDDD format. 
^This modifier causes the DDDDDDDDDD to be interpreted not 
as a Julian day number as it normally would be, but as
[http://en.wikipedia.org/wiki/Unix_time | Unix Time] - the 
number of seconds since 1970.  If the "unixepoch" modifier does not

  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 "<blockquote>$txt</blockquote>"
  hd_puts "<hr width=\"50%\">"
}

newsitem {2018-09-25} {Release 3.25.2} {
SQLite [version 3.25.2] is another patch against 3.25.0 that fixes still
more problems associated with the new [window function] feature and the
[ALTER TABLE] enhancements.  Of particular note is the new
[PRAGMA legacy_alter_table=ON] command, which causes the ALTER TABLE RENAME
command to behave in the same goofy way that it did before the enhancements
found in version 3.25.0 &rarr; references to renamed tables that are inside
the bodies of triggers and views are not updated.  The legacy behavior is
arguably a bug, but some programs depend on the older buggy behavior.  The
3.25.2 release also contains a fix to [window function] processing for
VIEWs.  There also a slew of other minor fixes that affect obscure
compile-time options.  See the
[https://sqlite.org/src/timeline?r=branch-3.25|Fossil Timeline] for
details.
}

newsitem {2018-09-18} {Release 3.25.1} {
SQLite [version 3.25.1] is a patch against version 3.25.0 that contains
two one-line fixes for bug that were introduced in version 3.25.0.
See the change log for details.  Upgrading from 3.25.0 is recommended.
}

  <p>^This pragma only operates on the single database specified prior
  to the pragma name (or on the "main" database if no database is specified.)
  There is no way to change the journal size limit on all attached databases
  using a single PRAGMA statement.  The size limit must be set separately for
  each attached database.
}


Pragma legacy_alter_table {
   <p>^(<b>PRAGMA legacy_alter_table;
       <br>PRAGMA legacy_alter_table = <i>boolean</i></b></p>
    <p>This pragma sets or queries the value of the legacy_alter_table
    flag.)^  ^(When this flag is on, the ALTER TABLE RENAME
    command (for changing the name of a table) works as it did
    in SQLite 3.24.0 ([dateof:3.24.0]) and earlier.)^  More specifically,
    when this flag is on
    the ALTER TABLE RENAME command only rewrites the initial occurrence
    of the table name in its CREATE TABLE statement and in any associated
    CREATE INDEX and CREATE TRIGGER statements.  Other references to the
    table are unmodifed, including:
    <ul>
    <li> References to the table within the bodies of triggers and views.
    <li> References to the table within CHECK constraints in the original
         CREATE TABLE statement.
    <li> References to the table within the WHERE clauses of [partial indexes].
    </ul>
    The default setting for this pragma is OFF, which means that all
    references to the table anywhere in the schema are converted to the new name.
    <p>This pragma is provided as a work-around for older programs that
    contain code that expect the incomplete behavior
    of ALTER TABLE RENAME found in older versions of SQLite.
    New applications should leave this flag turned off.
    <p>For compability with older [virtual table] implementations,
    this flag is turned on temporarily while the [sqlite3_module.xRename]
    method is being run.  The value of this flag is restore after the 
    [sqlite3_module.xRename] method finishes.
}

Pragma legacy_file_format {
   <p>^(<b>PRAGMA legacy_file_format;
       <br>PRAGMA legacy_file_format = <i>boolean</i></b></p>
    <p>This pragma sets or queries the value of the legacy_file_format
    flag.)^  ^(When this flag is on, new SQLite databases are created in
    a file format that is readable and writable by all versions of

</codeblock>

<p>This method provides notification that the virtual table implementation
that the virtual table will be given a new name. 
If this method returns [SQLITE_OK] then SQLite renames the table.
If this method returns an [error code] then the renaming is prevented.

<p>The xRename method is optional.  If omitted, then the virtual
table may not be renamed using the ALTER TABLE RENAME command.

<p>The [PRAGMA legacy_alter_table] setting is enabled prior to invoking this
method, and the value for legacy_alter_table is restored after this
method finishes.  This is necessary for the correct operation of virtual
tables that make use of [shadow tables] where the shadow tables must be
renamed to match the new virtual table name.  If the legacy_alter_format is
off, then the xConnect method will be invoked for the virtual table every
time the xRename method tries to change the name of the shadow table.

<tcl>############################################################# xSavepoint
hd_fragment xsavepoint {sqlite3_module.xSavepoint} {xSavepoint}\
  xRelease xRollbackTo</tcl>
<h2>The xSavepoint, xRelease, and xRollbackTo Methods</h2>

<codeblock>

<tcl>hd_keywords {window functions} {window function}</tcl>

<title>Window Functions</title>
<table_of_contents>

<h1>Introduction to Window Functions</h1>

<p>A window function is a special SQL function where the input

for all ORDER BY expressions are considered peers regardless of the frame type.

<p> Most built-in window functions ignore the
<yynonterm>frame-spec</yynonterm>, the exceptions being first_value(),
last_value() and nth_value(). It is a syntax error to specify a FILTER 
clause as part of a built-in window function invocation.

<tcl>hd_fragment biwinfunc {builtin window functions}</tcl>
<p> SQLite supports the following 11 built-in window functions:

<dl>
  <dt><p><b>row_number()</b>
  <dd><p> The number of the row within the current partition. Rows are
       numbered starting from 1 in the order defined by the ORDER BY clause in
       the window definition, or in arbitrary order otherwise.