What is the Visual DDL Editor in Jam SQL Studio?

The Visual DDL Editor is a set of structural-edit affordances that appear directly inside the Query Editor when your cursor sits on a DDL statement (CREATE TABLE, ALTER TABLE, CREATE VIEW, CREATE SEQUENCE, CREATE TRIGGER, CREATE PROCEDURE, CREATE FUNCTION, and more). Instead of typing the ALTER syntax yourself, you use small popovers to add or drop columns, edit constraints, change sequence parameters, and so on — and the change is patched back into your SQL buffer byte-for-byte.

How do I open the Visual DDL Editor?

Place your cursor anywhere inside a supported DDL statement in the Query Editor. A floating inline DDL toolbar appears above the statement automatically. Click any button on that toolbar to open the matching structural-edit popover. No separate workspace tab is required.

Does the Visual DDL Editor execute changes against the database automatically?

No. The inline DDL toolbar writes changes to the SQL buffer — it never executes against the database on its own. Run the buffer yourself with Execute (F5) when you are ready, exactly as you would any other SQL. The Table Designer behaves differently: its Save Changes button executes the coalesced ALTER chain in a transaction.

What is source-preserving editing?

Every structural edit uses byte-range patching: only the bytes that correspond to the thing you changed are rewritten. Whitespace, comments, identifier quoting style, and casing in every other part of the statement are preserved exactly as you typed them. Cmd/Ctrl+Z reverts the change as a single atomic Monaco history entry — there is no separate Visual DDL Editor undo stack.

Which SQL engines does the Visual DDL Editor support?

The Visual DDL Editor supports SQL Server, PostgreSQL, MySQL/MariaDB, Oracle, and SQLite. Individual affordances that a given engine does not support (for example, CREATE SEQUENCE on MySQL and SQLite) are disabled with an explanatory tooltip rather than hidden silently.

Last updated: 2026-07-04

Visual DDL Editor

Edit DDL statements through visual popovers without leaving the Query Editor. Place your cursor on a CREATE TABLE, ALTER TABLE, CREATE VIEW, CREATE SEQUENCE, CREATE TRIGGER, CREATE PROCEDURE, CREATE FUNCTION, or any other top-level DDL statement and a floating toolbar appears above it — click a button to add a column, edit a sequence parameter, or change a trigger's target, and the change is written back into your SQL buffer byte-for-byte.

Buffer is always the source of truth. The Visual DDL Editor writes structural edits back into the same Monaco buffer you typed. Cmd/Ctrl+Z reverts any edit exactly as it would a manual keystroke — there is no parallel undo stack.

Why a visual edit surface for DDL?

DDL syntax varies by engine, and the syntax you want is often buried under dialect-specific clauses you have to look up. The Visual DDL Editor knows the dialect rules for SQL Server, PostgreSQL, MySQL/MariaDB, Oracle, and SQLite, so you pick from structured fields instead of typing raw SQL. The result lands in your buffer as valid dialect-correct syntax, with your existing whitespace, comments, and quoting style intact.

The edit surface is deliberately narrow: it covers the structural parts of a statement (column list, constraint list, sequence parameters, routine signature) but leaves the procedural body inside CREATE PROCEDURE / CREATE FUNCTION / CREATE TRIGGER as opaque text. Edit the body directly in Monaco; the Visual DDL Editor handles the shell.

Entry point — the inline DDL toolbar

Inside any Query Editor, a small floating toolbar appears above the statement under your cursor when the statement is a supported DDL kind. The toolbar shows object-aware buttons: CREATE TABLE shows Add Column / Constraints / Indexes / Storage; CREATE SEQUENCE shows Edit Parameters; CREATE TRIGGER shows Edit Shell, and so on.

Inline DDL toolbar floating above a CREATE TABLE statement with object-aware buttons. — The inline DDL toolbar lights up when the cursor parks on any supported DDL statement — here on a `CREATE TABLE`, showing the Column / Constraint / Index / Rename / Move to schema / Tablespace / Engine Options buttons.

The DDL toolbar and the Visual Query Editor inline toolbar are mutually exclusive — only the one that matches the cursor's statement kind is active at a time. CREATE TABLE … AS SELECT … is treated as DDL (the outer statement wins).

Source-preserving guarantee

Every edit goes through the engine's applyDdlEdit + emitSource primitives. The edit is expressed as a byte-range patch: only the bytes that need to change are rewritten; everything else — whitespace, indentation, comments between columns, identifier quoting, casing — is preserved byte-for-byte. The patch lands as a single tagged Monaco history entry, so Cmd/Ctrl+Z reverts the structural change atomically.

What the guarantee does not cover: the content of procedural bodies (BEGIN … END, PL/pgSQL $$…$$, T-SQL batches) is opaque to the DDL editor. If you use the Visual DDL Editor to add a parameter to a CREATE PROCEDURE, the body text is preserved verbatim; the patch only touches the parameter list. Formatting or whitespace normalization of the body never happens.

Apply posture — no implicit execute

The inline DDL toolbar mutates the buffer; it never executes the resulting DDL against the database on its own. When you are satisfied, run the buffer with Execute (F5) or Execute Selection as you would any other SQL.

The Table Designer behaves differently: its Save Changes button executes the coalesced ALTER chain in a transaction. Use Table Designer when you want one-click schema changes committed immediately; use the inline DDL toolbar when you want to compose or review DDL in the buffer first.

What lights up per object kind

The buttons and popovers available on the inline DDL toolbar change to match the statement kind under the cursor. The table below lists what each kind exposes.

Object kind	Structural edit affordances
`CREATE / ALTER TABLE`	Add / edit / drop columns; manage constraints (PK, FK, UNIQUE, CHECK, named DEFAULT); manage indexes (filtered, INCLUDE, expression, specialized); partitioning and tablespace options.
`CREATE / ALTER VIEW`	Edit the SELECT body via the embedded Visual Query Editor; toggle `WITH CHECK OPTION` and engine-specific shell clauses.
`CREATE MATERIALIZED VIEW`	Same body editing as views, plus `REFRESH` mode (manual / on-commit / scheduled, per engine support).
`CREATE SEQUENCE`	Edit start value, increment, minimum, maximum, cycle flag, and cache size. Disabled with a tooltip on MySQL and SQLite, which do not have `CREATE SEQUENCE`.
`CREATE TYPE / DOMAIN`	Edit composite-type fields, enum values (per engine), domain base type, default expression, and check constraints.
`CREATE SCHEMA`	Edit schema name and owner / authorization clause. Disabled on SQLite.
`CREATE TRIGGER`	Edit timing (BEFORE / AFTER / INSTEAD OF), event (INSERT / UPDATE / DELETE), target table, and condition. The body remains opaque text edited directly in Monaco.
`CREATE PROCEDURE / FUNCTION`	Edit parameter list (with mode IN / OUT / INOUT per engine), RETURNS clause, and options (VOLATILITY, DETERMINISTIC, SECURITY DEFINER, OR REPLACE, etc.). The procedural body is not touched.
`CREATE / ALTER LOGIN / USER / ROLE`	Edit name, authentication, default schema, and role memberships through the security form popover. SQL Server surfaces LOGIN and USER as distinct object kinds; PostgreSQL and Oracle use ROLE; MySQL uses USER. Disabled on SQLite, which has no user or role model.
`GRANT / REVOKE`	Edit privileges (multi-select), the target object, and grantees through the privilege form popover. Supports WITH GRANT OPTION, REVOKE CASCADE (MSSQL and PostgreSQL), ALL PRIVILEGES shortcut (PostgreSQL), and per-engine privilege sets. Disabled on SQLite, which has no authorization model.
`CREATE / ALTER DATABASE`	Edit database name and engine-specific options (MSSQL: containment + collation; PostgreSQL: encoding / locale / template; MySQL: character set + collation; Oracle: admin user + PDB hints). Disabled on SQLite — SQLite databases are filesystem files managed outside SQL DDL.
`DROP …` (any object)	No structural edit affordances — the inline toolbar is intentionally absent for DROP statements. The pre-destructive guard (blast-radius panel) still fires if the dropped object has incoming dependents.

Canonical example — ALTER TABLE / ADD COLUMN

Place your cursor on a CREATE TABLE or ALTER TABLE statement. The inline DDL toolbar appears with an Add Column button. Click it to open the add-column popover:

Type the column name.
Pick the data type from the dropdown (populated with the dialect-correct type list for the active engine).
Set nullable, default value, and any identity / generated column options.
Click Apply.

For a CREATE TABLE source, the new column is inserted at the end of the column list. For an ALTER TABLE source, a dialect-correct ALTER TABLE … ADD COLUMN clause is appended after the existing statement. In both cases only the bytes that represent the new column are written; every other byte in the buffer is untouched.

Dialect differences are handled automatically. On SQL Server, the emitted clause uses ALTER TABLE … ADD without the COLUMN keyword. On MySQL an ALTER TABLE … ADD COLUMN is emitted as a standalone statement. On SQLite, adding a column with certain constraint combinations that SQLite's ALTER TABLE does not support is flagged as unsupported with a clear error — no silent broken DDL.

Add-column popover form over the visual table designer, showing column name, data type, nullable, and default value fields. — The add-column form — shown here on the Table Designer surface, which uses the same structural-edit primitives as the inline toolbar's Column popover. Submitting emits the ALTER and rewrites the buffer in place.

Preview dialog

Every structural edit — in the Table Designer or the Query Editor inline toolbar — always prompts a preview dialog before committing to the buffer. The dialog shows exactly what will change as a diff; you can review, confirm, or cancel. Because DDL changes your schema, the preview is always on and is not byte-gated.

The Settings → UI → Visual editing → Preview threshold setting no longer affects the Visual DDL Editor — it now applies only to the Visual Query Editor (DML edits). If you cancel a DDL preview the buffer is left untouched; after you apply, use Cmd/Ctrl+Z to undo if the result is not what you wanted.

Blast-radius dialog for DROP operations

When the cursor parks on a DROP TABLE, DROP COLUMN, DROP VIEW, or DROP SEQUENCE statement that has incoming dependents in the database, the inline DDL toolbar surfaces a blast-radius panel proactively — before you run the buffer. The panel lists every dependent object (FK sources, views, routines, triggers) with one-click jump-to links and warns if any drop will cascade.

The blast-radius check requires an active database connection so the catalog can be queried. For DROP statements on objects with zero dependents the panel does not appear — no friction when there is nothing to lose.

Blast-radius guard dialog listing dependent objects before a destructive drop-column edit. — The blast-radius guard — shown here on the Table Designer surface, which shares the same guard as the inline toolbar — lists dependent objects before a destructive drop so you can confirm, cancel, or jump to each.

Application code is not checked. The blast-radius panel finds references in the database catalog. Application code that constructs SQL dynamically at runtime (ORM queries, stored parameter bindings) may also depend on the dropped object — review before proceeding.

Engine support and disabled affordances

Affordances that the active engine does not support are disabled with an explanatory tooltip rather than hidden or silently degraded. Examples:

Filtered (partial) indexes are disabled on MySQL and Oracle.
CREATE SEQUENCE editing is disabled on MySQL and SQLite.
GRANT / REVOKE editing is disabled on SQLite.
Partitioning controls are disabled on SQLite.
INCLUDE (covering) columns are disabled on MySQL, Oracle, and SQLite.

For a full engine × operation breakdown, see the alter-matrix coverage report at Ralph/NavigationalFeatures/ALTER_MATRIX_COVERAGE.md in the source tree.

Multi-engine notes

Column rename uses dialect-native emit: SQL Server emits EXEC sp_rename 'schema.table.old', 'new', 'COLUMN'; PostgreSQL, MySQL, Oracle, and SQLite emit ALTER TABLE … RENAME COLUMN old TO new. No per-dialect knowledge is required from the caller — the engine is detected from the active connection and the correct form is emitted automatically.

Identifier quoting follows the source statement's existing style. If your CREATE TABLE quotes the table name with brackets ([MyTable]) on SQL Server, newly synthesized clauses use brackets for any new identifiers in that statement.

Popover keyboard shortcuts

Action	macOS	Windows / Linux
Dismiss the popover without committing	`Escape`	`Escape`

See the full keyboard shortcuts reference for the complete list.

Related surfaces

Table Designer — visual table creation and modification with immediate Save + execute. The Table Designer reuses the same DDL structural-edit primitives as the inline toolbar, adding a full constraint / index / storage UI and a transaction-wrapped Save.
Visual Query Editor — structural read + edit for SELECT, INSERT, UPDATE, DELETE, and MERGE statements. The two toolbars are mutually exclusive; the cursor's statement kind determines which one is active.
Query Editor — write and execute SQL. The inline DDL toolbar lives here, inside the Monaco editor.
Keyboard shortcuts — full reference for all surfaces.