pub struct BoundDelete {
pub table: TableInfo,
pub index_exprs: Vec<BoundIndexExprs>,
pub index_hint: IndexChoice,
pub source: usize,
pub filter: Option<BoundExpr>,
pub returning: Vec<BoundResultColumn>,
pub order_by: Vec<BoundOrderTerm>,
pub limit: Option<BoundExpr>,
pub offset: Option<BoundExpr>,
pub triggers: Vec<BoundTrigger>,
pub view_rows: Option<Box<BoundSelect>>,
}Expand description
A bound DELETE.
Fields§
§table: TableInfoThe table being written.
index_exprs: Vec<BoundIndexExprs>The expressions the table’s partial and expression indexes need.
A delete needs them too: an entry only comes out of a partial index if the row was in it, and a key the index computed has to be recomputed to be found.
index_hint: IndexChoiceINDEXED BY or NOT INDEXED on the target, as on BoundUpdate.
source: usizeThe statement-wide number of the FROM term being written.
It used to be implicitly zero, because a DML statement had exactly one source. A trigger body is compiled into the statement that fires it, so its target takes the next number after the firing statement’s - and a compiler that assumed zero read the wrong cursor for every fire after the first.
filter: Option<BoundExpr>The WHERE clause.
returning: Vec<BoundResultColumn>The RETURNING columns.
order_by: Vec<BoundOrderTerm>The ORDER BY that decides which rows a LIMIT keeps.
Empty unless the statement wrote one, and then always with a LIMIT,
because the binder refuses an order with nothing to limit. It goes onto
the query that finds the rows to change, which is where SQLite puts it
too: a limited write is WHERE rowid IN (SELECT rowid ... ORDER BY ... LIMIT ...) there.
limit: Option<BoundExpr>The LIMIT.
offset: Option<BoundExpr>The OFFSET.
triggers: Vec<BoundTrigger>The triggers this write fires, in schema order.
view_rows: Option<Box<BoundSelect>>The rows to fire an INSTEAD OF trigger for, when the target is a view.