pub struct ColumnInfo {Show 14 fields
pub name: Vec<u8>,
pub folded: Vec<u8>,
pub declared_type: Vec<u8>,
pub affinity: Affinity,
pub collation: Vec<u8>,
pub not_null: bool,
pub not_null_conflict: Option<ConflictAction>,
pub primary_key_conflict: Option<ConflictAction>,
pub default_sql: Option<Vec<u8>>,
pub primary_key_position: Option<u16>,
pub hidden: bool,
pub generated: bool,
pub stored: bool,
pub generated_sql: Option<Vec<u8>>,
}Expand description
One column of a table or view.
Fields§
§name: Vec<u8>The name as declared.
folded: Vec<u8>The ASCII-folded lookup key.
declared_type: Vec<u8>The declared type, exactly as written, empty when none was given.
affinity: AffinityThe affinity derived from the declared type.
collation: Vec<u8>The folded name of the column’s declared collation.
not_null: boolWhether the column is NOT NULL.
not_null_conflict: Option<ConflictAction>The ON CONFLICT clause written on the NOT NULL, when there was one.
A constraint carries its own algorithm and the statement may override
it: INSERT OR IGNORE beats NOT NULL ON CONFLICT ABORT. Recording it
per constraint rather than per table is what makes that override a
choice between two known values instead of a guess.
primary_key_conflict: Option<ConflictAction>The ON CONFLICT clause written on the column’s PRIMARY KEY.
A different constraint from the NOT NULL, and a different clause.
For a rowid alias this is the only place a rowid collision’s algorithm
is written down - SQLite records id INTEGER PRIMARY KEY ON CONFLICT REPLACE against the column, because the alias is the column and there
is no index to hang it on. Every other primary key gets an IndexInfo
and carries it there.
Reading not_null_conflict for it, which is what the write path used to
do, answers a question about a constraint the table may not
even declare.
default_sql: Option<Vec<u8>>The DEFAULT expression, as written.
primary_key_position: Option<u16>The one-based position in the primary key, when it is in one.
Whether the column is hidden from SELECT *.
generated: boolWhether the column is generated.
stored: boolWhether a generated column’s value is stored in the record.
A VIRTUAL column occupies no slot and is computed on every read; a
STORED one occupies a slot like any other column. The distinction is
not cosmetic: it changes which record position every column after it
lives at, so a reader that ignored it would read the wrong column.
generated_sql: Option<Vec<u8>>The generating expression, as the source text it was written as.
Implementations§
Source§impl ColumnInfo
impl ColumnInfo
Sourcepub fn is_vector(&self) -> bool
pub fn is_vector(&self) -> bool
Reports whether the column was declared a vector at all.
VECTOR(768) and a bare VECTOR both answer true, where
ColumnInfo::vector_dimensions answers a width only for the first.
The difference matters to the operators: a bare VECTOR cannot be
indexed, but adding two of them is just as meaningless.
Sourcepub fn vector_dimensions(&self) -> Option<usize>
pub fn vector_dimensions(&self) -> Option<usize>
Returns how many dimensions a VECTOR(N) column declares.
Read out of the declared type rather than stored beside it, because
every path that builds a ColumnInfo - the catalog loader, a module’s
declaration, the binder’s synthetic ones - would otherwise have to know
about vectors, and a column’s declared type is the one place SQLite
itself keeps what a column was called.
VECTOR(768) and vector( 768 ) both answer 768. A bare VECTOR
answers None, which means “a vector of whatever arrives” and is what a
table holding two models’ embeddings needs; anything that is not a
vector answers None too, and its caller then checks nothing.
The affinity is deliberately left alone. SQLite gives VECTOR(768)
NUMERIC affinity, and NUMERIC leaves a blob exactly as it arrived - so
the bytes round-trip without this engine having to disagree with the
reference about what an affinity is. What the declaration buys is the
width check on write, and a column an index can be built over.