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 | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA3-256: |
8cd33c0c9dde882103ae77daa31ba316 |
| User & Date: | drh 2019-11-07 12:48:54 |
Context
|
2019-11-14
| ||
| 18:57 | Documentation on hard-heap-limit. check-in: 2252627a39 user: drh tags: trunk | |
|
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. check-in: 8cd33c0c9d user: drh tags: trunk | |
|
2019-11-02
| ||
| 18:17 | Update the keyword list. check-in: 6904f495e9 user: drh tags: trunk | |
Changes
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 |