Last updated: 2026-09-14

Visual DDL Editor

Edit DDL statements through a compact popup 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, then click the pencil "Edit" affordance next to it — the Compact DDL editor opens, and you add a column, edit a sequence parameter, or change a trigger's target from there, with the change written back into your SQL buffer byte-for-byte.

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 pencil affordance and the Compact DDL editor

The Visual DDL Editor is a beta feature and shares its switch with the Visual Query Editor: tick Visual Query Editor under Settings → Beta Features and the pencil described below appears on DDL statements too. The Table Designer workspace is always available.

Inside any Query Editor, a pencil "Edit" affordance appears next to the statement under your cursor when the statement is a supported DDL kind. Click it to open the Compact DDL editor — a small resizable popup scoped to that one statement.

For CREATE TABLE / ALTER TABLE, the popup hosts a mini structure editor with Columns, Constraints, Indexes, and Storage tabs, plus header actions for Rename and Move to schema — the same editor Table Designer uses, in a denser layout. For every other supported kind — views, materialized views, sequences, types/domains, schemas, triggers, procedures/functions, logins/users/roles, GRANT/REVOKE, and databases — the popup opens directly into that kind's edit form, since there are only one or two fields to change.

A Design Table footer button (table statements only) promotes the statement to the full Table Designer workspace tab; an Edit as SQL footer button closes the popup and returns focus to the buffer. When a statement can't be resolved into an editable structure, the popup falls back to a read-only summary card describing what it can tell about the statement, with Design Table disabled and a reason tooltip.

Editing works without a live database connection — only connection-dependent affordances (Design Table, dependency lookups) disable individually, each with a tooltip explaining why.

The Compact DDL editor and the Visual Query Editor's compact popover are mutually exclusive — only the one that matches the cursor's statement kind opens. 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 Compact DDL editor 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 Compact DDL editor when you want to compose or review DDL in the buffer first.

What lights up per object kind

The tabs and forms the Compact DDL editor opens change to match the statement kind under the cursor. The table below lists what each kind exposes.

Canonical example — ALTER TABLE / ADD COLUMN

Place your cursor on a CREATE TABLE or ALTER TABLE statement and click the pencil affordance. The Compact DDL editor opens on the Columns tab. Click Add Column to open the add-column popover:

1. Type the column name.
2. Pick the data type from the dropdown (populated with the dialect-correct type list for the active engine).
3. Set nullable, default value, and any identity / generated column options.
4. 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.

Preview dialog

Every structural edit — in the Table Designer or the Compact DDL editor — 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.

Reviewing dependents before a drop

Opening the Compact DDL editor on a DROP TABLE, DROP VIEW, DROP SEQUENCE, or other object-drop statement shows a Check dependents action (requires an active connection). Click it to open the object in the Dependency Viewer and review every dependent (FK sources, views, routines, triggers) with one-click jump-to links before you run the buffer.

The pre-destructive blast-radius panel guard is separate and unchanged: when you drop a constraint or index through the visual editor and the affected object has incoming dependents, the guard pauses with a confirm/cancel dialog listing every dependent object before the change lands in the buffer. It does not fire for zero-dependent drops — no friction when there is nothing to lose.

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.

The one exception is a concept the engine simply does not have, where a disabled control would never become usable and would only take up space: SQL Server's named DEFAULT constraint objects. On PostgreSQL, MySQL, Oracle, and SQLite, defaults are column attributes rather than named objects, so the Constraints tab omits that row entirely — set the default from the column form instead.

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

MySQL account names and passwords preserve quotes and backslashes. For password edits that need mode-dependent escaping, a connected editor checks the current session SQL mode before preview or apply; a failed check asks you to reconnect. Disconnected edits use MySQL's default backslash-escape mode, so review the SQL mode before running that script elsewhere.

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.

Quoted and unquoted column names

A column's identity is its name plus its quoting. On PostgreSQL and Oracle an unquoted Id is folded by the server — to id on PostgreSQL, ID on Oracle — while a quoted "Id" keeps its exact characters, so those are two different columns. The editor reads which column the statement in your buffer declared and emits a clause naming that column: editing one the source wrote as "Id" produces an ALTER naming "Id", never the folded id. It preserves the identity rather than copying the quote marks: where a name needs no quotes to be read exactly, the clause may leave them off — and a clause that follows its statement's own quoting style, such as one added to a table the source wrote as "t", keeps them.

One statement can declare both. CREATE TABLE t (Id integer, "Id" integer) is two different columns on PostgreSQL and Oracle — id and Id on PostgreSQL, ID and Id on Oracle — and the Columns tab lists both. Each row's Edit button edits the column that row came from, so those edits need nothing extra from you.

In an index column list, an entry that carries index syntax rather than just a name — Id DESC, LOWER(email), a MySQL prefix length such as name(10), or a PostgreSQL operator class — is passed through to the server exactly as you type it. Those entries are never rewritten and never refused, so write the quotes you want in them yourself.

A few keywords are treated the same way for the same reason. On Oracle and SQLite, CREATE INDEX … (NULL) is a valid index on the constant, so an unquoted NULL is left alone there rather than read as a column of that name — if you have a column called NULL, type "NULL" to index it. Oracle does the same for nine words in all: NULL, its four floating-point literals (BINARY_DOUBLE_NAN, BINARY_FLOAT_NAN, BINARY_DOUBLE_INFINITY, BINARY_FLOAT_INFINITY) and all four ORA_INVOKING_* functions (ORA_INVOKING_USER, ORA_INVOKING_USERID, ORA_INVOKING_XS_USER, ORA_INVOKING_XS_USER_GUID), each of which it indexes as an expression. Every other engine rejects (NULL) outright, so there the unquoted spelling is read as the column, like any other name.

Popover keyboard shortcuts

See the full keyboard shortcuts reference for the complete list.

Frequently asked questions

Related surfaces

• Table Designer — visual table creation and modification with immediate Save + execute, now a full-bleed workspace tab. Table Designer reuses the same DDL structural-edit primitives as the Compact DDL editor, 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, opened from the same pencil affordance and popover host. Only the popup that matches the cursor's statement kind opens.
• Query Editor — write and execute SQL. The pencil affordance and Compact DDL editor live here, inside the Monaco editor.
• Keyboard shortcuts — full reference for all surfaces.