Documentation Source Text

CREATE VIRTUAL TABLE demo_index USING rtree(
   id,              -- Integer primary key
   minX, maxX,      -- Minimum and maximum X coordinate
   minY, maxY       -- Minimum and maximum Y coordinate
);
</codeblock>

























<h2>Populating An R*Tree Index</h2>

<p>
^The usual [INSERT], [UPDATE], and [DELETE] commands work on an R*Tree
index just like on regular tables.  ^(So to insert some data into our sample
R*Tree index, we can do something like this:
</p>
................................................................................
   AND minX&gt;=-81.0 AND maxX&lt;=-79.6
   AND minY&gt;=35.0 AND maxY&gt;=36.2;
</codeblock>)^

<h3>Limitations</h3>

<p>

Constraints on auxiliary columns such as NOT NULL, UNIQUE, REFERENCES, or CHECK
are silently ignored in the current implementation.  However, future versions
of SQLite might start enforcing one or more of those constraint types. Avoid using
constraints on auxiliary columns to prevent future compatibility problems.

<tcl>hd_fragment {intrtree} {integer-valued r-trees}</tcl>
<h1>Integer-Valued R-Trees</h1>

CREATE VIRTUAL TABLE demo_index USING rtree(
   id,              -- Integer primary key
   minX, maxX,      -- Minimum and maximum X coordinate
   minY, maxY       -- Minimum and maximum Y coordinate
);
</codeblock>

<h3>Column naming details</h3>

<p>
^(In the argments to "rtree" in the CREATE VIRTUAL TABLE statement, the
names of the columns are taken from the first token of each argument.
All subsequent tokens within each argument are silently ignored.)^
This means, for example, that if you try to give a column a
[type affinity] or add a constraint such as UNIQUE or NOT NULL or DEFAULT to
a column, those extra tokens are accepted as valid, but they do not change
the behavior of the rtree.
^(In an RTREE virtual table, the first column always has a
[type affinity] of INTEGER and all other data columns have a
[type affinity] of NUMERIC.)^

<p>
Recommended practice is to omit any extra tokens in the rtree specification.
Let each argument to "rtree" be a single ordinary label that is the name of
the corresponding column, and omit all other tokens from the argument list.

<p>
Slightly different rules apply to to <a href="#auxcol">auxiliary columns</a>.
The [type affinity] for an auxiliary column specified in the CREATE VIRTUAL
TABLE statement is honored, but other constraints on still ignored.

<h2>Populating An R*Tree Index</h2>

<p>
^The usual [INSERT], [UPDATE], and [DELETE] commands work on an R*Tree
index just like on regular tables.  ^(So to insert some data into our sample
R*Tree index, we can do something like this:
</p>
................................................................................
   AND minX&gt;=-81.0 AND maxX&lt;=-79.6
   AND minY&gt;=35.0 AND maxY&gt;=36.2;
</codeblock>)^

<h3>Limitations</h3>

<p>
The [type affinity] of auxiliary columns is honored.  However,
constraints on auxiliary columns such as NOT NULL, UNIQUE, REFERENCES, or CHECK
are silently ignored in the current implementation.  However, future versions
of SQLite might start enforcing one or more of those constraint types. Avoid using
constraints on auxiliary columns to prevent future compatibility problems.

<tcl>hd_fragment {intrtree} {integer-valued r-trees}</tcl>
<h1>Integer-Valued R-Trees</h1>