SQLlyDescriptions
functionalEdit table, view, and column descriptions and write them back to the server as comment DDL.
Tables, views, and columns can carry a description - the comment the database itself stores next to the object. SQLly reads those descriptions everywhere it shows the schema (the object inventory's Comment column, the schema documentation export, AI context), and you can write them from two places without hand-writing the engine's comment syntax.
Where to edit
- Edit Structure - a Description field for the table sits under the column list, and each column row has its own description box. Description edits appear in the change list as Set description. On most engines they are scripted after the structural changes; the comment belongs to the column, so a rename or retype needs no extra statement. On MySQL and MariaDB, where changing a column restates its whole definition, a column that is renamed, retyped, re-defaulted, or added carries its description inside that same clause, so it keeps (or gets) its comment and the structural change is not undone.
- Object properties - the General page of a table or view shows its live description in an editable field once it has been read. Changing it marks the page as modified; Review changes shows the exact statement before anything runs.
Clearing the text removes the description. Both surfaces follow the usual review rules: Edit Structure scripts to an editor tab, Object properties executes only from its review sheet.
If the current descriptions cannot be read (a permissions problem, for example), both surfaces hide the description field and show the reason instead. An edit is never scripted against a guessed value, because on SQL Server the right procedure depends on whether a description already exists.
What SQLly runs on each engine
| Engine | Table / view description | Column description |
|---|---|---|
| SQL Server / Azure SQL | The MS_Description extended property: sp_addextendedproperty when none exists, sp_updateextendedproperty when one does (including one that holds empty text), sp_dropextendedproperty to clear. Views are addressed as views. | The same procedures at column level. |
| PostgreSQL | COMMENT ON TABLE / COMMENT ON VIEW … IS '…'; IS NULL clears. | COMMENT ON COLUMN … IS '…'. |
| CockroachDB | COMMENT ON TABLE … IS '…'. CockroachDB has no COMMENT ON VIEW, so a view's description field is hidden with that reason. | COMMENT ON COLUMN … IS '…'. |
| DuckDB | COMMENT ON TABLE / COMMENT ON VIEW; IS NULL clears. | COMMENT ON COLUMN. |
| Oracle Database | COMMENT ON TABLE … IS '…' (Oracle addresses views with the TABLE keyword); IS '' clears. | COMMENT ON COLUMN. |
| MySQL / MariaDB | ALTER TABLE … COMMENT = '…'. Views cannot store a description (the server reports every view's comment as VIEW), so the view's field is hidden with that reason. | MySQL has no statement that changes only a comment, so SQLly runs ALTER TABLE … MODIFY COLUMN. For a description-only change it restates the column exactly as SHOW CREATE TABLE prints it and replaces just the COMMENT '…' clause, keeping everything else, including clauses after the comment such as MariaDB's CHECK (json_valid(…)); if that text cannot be read, SQLly refuses the change rather than guess. When the same edit also renames, retypes, re-defaults, or adds the column, the COMMENT goes into that CHANGE/MODIFY/ADD clause instead. |
| ClickHouse | ALTER TABLE … MODIFY COMMENT '…'. Views cannot be commented after creation; SQLly tells you to recreate the view with a COMMENT clause. | ALTER TABLE … COMMENT COLUMN … '…'. |
| SQLite / libSQL | No server-side comment store. The description fields are hidden and the editor shows the reason instead. | |
Text is quoted for the engine: embedded quotes are doubled everywhere, SQL Server
values are sent as Unicode N'…' literals, and MySQL and ClickHouse also
escape backslashes.
On MySQL and MariaDB, a column that Edit Structure renames, retypes, or re-defaults is rebuilt from the editor's fields: its type, nullability, default, auto-increment, its ON UPDATE (for timestamp and datetime columns), and its description. A character set or collation override, a generated expression, INVISIBLE, or a column-level CHECK is not restated; when the current definition has one, the script says so in a -- WARNING line so you can add it to the type before running.
