razeri-plugin-contract
The contract a Razeri dialect plugin is written against.
This crate and razeri-plugin-api are the two open crates in Razeri's workspace. Everything a plugin author needs in order to describe and render a database platform lives here; nothing else does. It depends on serde and on nothing else at all, which is what lets a plugin be built, published and consumed outside Razeri's repository.
What is in here
The rendering hierarchy — ten traits, layered so that a new dialect implements four required methods and inherits ANSI-standard behaviour for the rest:
| Trait | What it renders |
|---|---|
SqlRenderer |
Core SQL — the four required methods |
ExpressionRenderer |
Expressions, with ANSI defaults |
DdlRenderer |
DDL, with ANSI defaults |
DmlRenderer |
DML, with ANSI defaults |
ProcedureRenderer |
Stored procedures and functions |
FormulaRenderer |
Formulas, with ANSI defaults |
TaskRenderer |
Scheduled tasks |
ReplicationRenderer |
Data extraction, loading and key-function deployment |
StorageRenderer |
Partitioning, compression and index strategy |
DialectCapabilities |
What the platform's SQL can and cannot do |
The vocabulary those traits speak: DataType and DataTypeRef, the StoragePlan a StorageRenderer translates, the StoragePlatform a storage plugin names, and DialectFamily, the platform's own identity.
The decisions a dialect states rather than a core crate deciding for it — starting with SidSpelling, how this engine spells a surrogate key.
AnsiDialect is a complete worked implementation of the required methods, and render_data_type_ansi is the ANSI type mapping to start from.
What is deliberately not in here
Razeri's design model, its surrogate-key derivation, and every renderer that produces Razeri's own output. A plugin says what its engine spells; Razeri composes.
License
Dual-licensed under MIT or Apache 2.0, at your option. Plugins belong to their authors.