feature: Table DDL #90

New issue

Closed

opened 2026-07-15 13:45:00 -05:00 by noe.trevino · 1 comment

noe.trevino commented

2026-07-15 13:45:00 -05:00

Owner

Did you check the docs?

I have read all the dadbod-ui.nvim docs

I want to be able to script as with tables
This will let me alter tables easier

Describe the solution you'd like

DDL generation, like what we have for stored procs today

Describe alternatives/other solutions you've considered

manual generation, too cumbersom

Additional context

No response

### Did you check the docs? - [x] I have read all the dadbod-ui.nvim docs ### Is your feature request related to a problem? Please describe. I want to be able to `script as` with tables This will let me `alter` tables easier ### Describe the solution you'd like DDL generation, like what we have for stored procs today ### Describe alternatives/other solutions you've considered manual generation, too cumbersom ### Additional context _No response_

noe.trevino commented

2026-07-16 06:50:55 -05:00

Author

Owner

Moving the implementation notes here from CURRENT_SUPPORT.md, since this issue is where the work gets tracked.

This is not one feature, it splits hard by engine. Tables and routines arent symmetric: postgres hands you pg_get_functiondef for a routine but has no pg_get_tabledef.

Engine	`CREATE TABLE` strategy	Effort
SQLite	`SELECT sql FROM sqlite_master`, returns the original DDL verbatim	trivial
MySQL / MariaDB	`SHOW CREATE TABLE`	trivial
ClickHouse	`SHOW CREATE TABLE`	trivial
Oracle	`DBMS_METADATA.GET_DDL`	easy
Postgres	hand assemble, lean on `pg_get_constraintdef` / `pg_get_indexdef`	real work
SQL Server	hand assemble, SSMS itself does this client side	real work

Suggested phasing:

The non DDL actions first. SELECT To, INSERT To, UPDATE To, DELETE To, DROP To need only the column list, not CREATE TABLE. They are generatable server side in the style postgres.lua already uses, and they ship a useful menu on every adapter without touching the hard part.
The free tier: SQLite, MySQL/MariaDB, ClickHouse, Oracle CREATE To. One query each.
Postgres CREATE To, one server built query.
SQL Server CREATE To, the hardest.

Honest caveat: the tail on 3 and 4 is unbounded. Identity vs serial, collations, generated columns, storage params, partitioning, inheritance. Each is small, they never stop arriving, and each absence reads as a bug. Aim for good enough, honestly labeled.

The plumbing is mostly in place: routine_script.lua never branches on kind internally, drawer/actions.lua dispatches via on_activate with no type branches, Query:write_script already takes { table, schema }, and table nodes are already expandable with children.

Moving the implementation notes here from `CURRENT_SUPPORT.md`, since this issue is where the work gets tracked. This is not one feature, it splits hard by engine. Tables and routines arent symmetric: postgres hands you `pg_get_functiondef` for a routine but has no `pg_get_tabledef`. | Engine | `CREATE TABLE` strategy | Effort | | --- | --- | --- | | SQLite | `SELECT sql FROM sqlite_master`, returns the original DDL verbatim | trivial | | MySQL / MariaDB | `SHOW CREATE TABLE` | trivial | | ClickHouse | `SHOW CREATE TABLE` | trivial | | Oracle | `DBMS_METADATA.GET_DDL` | easy | | Postgres | hand assemble, lean on `pg_get_constraintdef` / `pg_get_indexdef` | real work | | SQL Server | hand assemble, SSMS itself does this client side | real work | Suggested phasing: 1. The non DDL actions first. `SELECT To`, `INSERT To`, `UPDATE To`, `DELETE To`, `DROP To` need only the column list, not `CREATE TABLE`. They are generatable server side in the style `postgres.lua` already uses, and they ship a useful menu on every adapter without touching the hard part. 2. The free tier: SQLite, MySQL/MariaDB, ClickHouse, Oracle `CREATE To`. One query each. 3. Postgres `CREATE To`, one server built query. 4. SQL Server `CREATE To`, the hardest. Honest caveat: the tail on 3 and 4 is unbounded. Identity vs serial, collations, generated columns, storage params, partitioning, inheritance. Each is small, they never stop arriving, and each absence reads as a bug. Aim for good enough, honestly labeled. The plumbing is mostly in place: `routine_script.lua` never branches on `kind` internally, `drawer/actions.lua` dispatches via `on_activate` with no type branches, `Query:write_script` already takes `{ table, schema }`, and table nodes are already expandable with children.