razeri-plugin-contract 0.3.2

The dialect contract Razeri plugins are written against — rendering traits, data types, platform identity
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

# razeri-plugin-contract

The contract a [Razeri](https://github.com/gaoash/razeri) dialect plugin is written against.

This crate and [`razeri-plugin-api`](https://crates.io/crates/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, and continuing with `ProcedureForm`, `ScalarFunctionForm` and `TableFunctionForm`, the routine grammars it speaks. Each of the three carries a `Custom` arm for a grammar Razeri does not know: your dialect names it and renders the routine itself, from the `RoutineSpec` Razeri hands over.

**The surrogate key's composition** — `sid::sid_expression` turns a `SidSpelling` into the key expression an engine runs. It is here because a dialect author who cannot render their own key expression cannot run it either, and *"the same key on every engine"* is then a claim nobody outside Razeri's repository can check.

`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 and every renderer that produces Razeri's own output. A plugin says what its engine spells; Razeri composes.

## License

Dual-licensed under [MIT](LICENSE-MIT) or [Apache 2.0](LICENSE-APACHE), at your option. Plugins belong to their authors.

## Security

Report a vulnerability through [GitHub's private vulnerability reporting](https://github.com/gaoash/razeri/security/advisories/new) on the Razeri repository — see its [security policy](https://github.com/gaoash/razeri/blob/main/SECURITY.md).