Documentation Source Text

Check-in [8cd33c0c9d]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Clarify what the file format ought to be when a WITHOUT ROWID table contains a PRIMARY KEY with redundant columns. This is not a change, but a filling in of previously omitted information.
Timelines: family | ancestors | trunk
Files: files | file ages | folders
SHA3-256: 8cd33c0c9dde882103ae77daa31ba3167746ece75a9b21c23e9692eafb042896
User & Date: drh 2019-11-07 12:48:54
Context
2019-11-07
12:48
Clarify what the file format ought to be when a WITHOUT ROWID table contains a PRIMARY KEY with redundant columns. This is not a change, but a filling in of previously omitted information. Leaf check-in: 8cd33c0c9d user: drh tags: trunk
2019-11-02
18:17
Update the keyword list. check-in: 6904f495e9 user: drh tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to pages/fileformat2.in.

1092
1093
1094
1095
1096
1097
1098





















1099
1100
1101
1102
1103
1104
1105
<p>^Hence, the content encoding for a WITHOUT ROWID table is the same
as the content encoding for an ordinary rowid table, except that the
order of the columns is rearranged so that PRIMARY KEY columns come
first, and the content is used as the key in an index b-tree rather
than as the data in a table b-tree.
^The special encoding rules for columns with REAL affinity
apply to WITHOUT ROWID tables the same as they do with rowid tables.






















<h2>Representation Of SQL Indices</h2>

<p>^Each SQL index, whether explicitly declared via a [CREATE INDEX] statement
or implied by a UNIQUE or PRIMARY KEY constraint, corresponds to an 
index b-tree in the database file.
^Each entry in the index b-tree corresponds to a single row in the 







>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>







1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
<p>^Hence, the content encoding for a WITHOUT ROWID table is the same
as the content encoding for an ordinary rowid table, except that the
order of the columns is rearranged so that PRIMARY KEY columns come
first, and the content is used as the key in an index b-tree rather
than as the data in a table b-tree.
^The special encoding rules for columns with REAL affinity
apply to WITHOUT ROWID tables the same as they do with rowid tables.

<h3>Suppression of redundant columns in the PRIMARY KEY
    of WITHOUT ROWID tables</h3>

<p>^If the PRIMARY KEY of a WITHOUT ROWID tables uses the same columns
with the same collating sequence more than once, then the second and
subsequent occurrences of that column in the PRIMARY KEY definition are
ignored.  ^(For example, the following CREATE TABLE statements all specify
the same table, which will have the exact same representation on disk:

<blockquote><pre>
CREATE TABLE t1(a,b,c,d,PRIMARY KEY(a,c)) WITHOUT ROWID);
CREATE TABLE t1(a,b,c,d,PRIMARY KEY(a,c,a,c)) WITHOUT ROWID);
CREATE TABLE t1(a,b,c,d,PRIMARY KEY(a,A,a,C)) WITHOUT ROWID);
CREATE TABLE t1(a,b,c,d,PRIMARY KEY(a,a,a,a,c)) WITHOUT ROWID);
</pre></blockquote>)^

<p>The first example above is the preferred definition of the table,
of course.  ^All of the examples create a WITHOUT ROWID table with
two PRIMARY KEY columns, "a" and "c", in that order, followed by
two data columns "b" and "d", also in that order.

<h2>Representation Of SQL Indices</h2>

<p>^Each SQL index, whether explicitly declared via a [CREATE INDEX] statement
or implied by a UNIQUE or PRIMARY KEY constraint, corresponds to an 
index b-tree in the database file.
^Each entry in the index b-tree corresponds to a single row in the