Enum Bound 

pub enum Bound {
    Query(Plan),
    CreateTable(CreateTable),
    CreateView(CreateView),
    DropTable(DropTable),
    Schema(SchemaChange),
    Sequence(SequenceChange),
    Type(TypeChange),
    Alter(Alter),
    Index(IndexChange),
    Insert(Insert),
    Setting(Setting),
    Checkpoint(Option<String>),
    Attach(Attach),
    Detach {
        name: String,
        if_exists: bool,
    },
    Transaction(Transaction),
    Explain {
        plan: Plan,
        analyze: bool,
        statistics: bool,
        codegen: bool,
    },
}

One statement, bound.

Not #[non_exhaustive]. A new variant here is a new kind of statement, and the compiler pointing at every place that has to decide what to do with it is the whole value of the enum.

Variants

Query(Plan)

A query, which is the only one of these that produces rows.

CreateTable(CreateTable)

CREATE TABLE.

CreateView(CreateView)

CREATE VIEW.

DropTable(DropTable)

DROP TABLE or DROP VIEW.

Schema(SchemaChange)

CREATE SCHEMA or DROP SCHEMA.

Sequence(SequenceChange)

CREATE SEQUENCE or DROP SEQUENCE.

Type(TypeChange)

CREATE TYPE or DROP TYPE.

Alter(Alter)

ALTER TABLE or ALTER VIEW.

Index(IndexChange)

CREATE INDEX or DROP INDEX.

Insert(Insert)

INSERT INTO.

Setting(Setting)

SET name = value, or RESET name, which is the same thing with no value.

Checkpoint(Option<String>)

Flushes a persistent database snapshot, of the named database when one is named.

Attach(Attach)

ATTACH.

Detach

DETACH, with the name and whether IF EXISTS was written.

Fields

name: String

if_exists: bool

Transaction(Transaction)

BEGIN, COMMIT or ROLLBACK, which have nothing to bind and are carried as written.

Explain

EXPLAIN over a query, holding the plan of the query rather than the query.

The same Plan a Bound::Query would have carried, bound the same way and by the same code. What makes it an explain is that the layer above optimizes it and prints it instead of running it, which is the point: a plan that was built differently because somebody asked to see it is not the plan that runs.

With analyze set the layer above runs it as well and prints what happened on it. Still the same plan, for the same reason.

With statistics set it prints what the planner knew as well, which is the use and the class behind every number in the plan. That one changes nothing about the plan or the run either.

With codegen set the layer above hands the plan to the compiled engine and prints what it generated instead.

Fields

plan: Plan

analyze: bool

statistics: bool

codegen: bool

Trait Implementations

impl Debug for Bound

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.