pythia-table

Tables, Columns, Comments

Announce at start: "Using pythia-table — reading the table and its neighbours before designing DDL."

Phase: Learn → Ask → Do — the table as it is, the decisions that are the developer's, then one ordered script

A table outlives every program that reads it. Its columns are a contract with every report, interface and procedure in the schema, and structural DDL has almost no undo: DROP COLUMN is permanent, a renamed column breaks every caller at once. Five minutes of design is the cheapest step there is.

The Iron Law

NO TABLE OR COLUMN WITHOUT ITS COMMENT, ITS CONSTRAINTS AND ITS IMPACT KNOWN

The Workflow

1. Learn the table and its neighbours.

• pythia cols T · pythia comments T · pythia stats T — what exists,

what is documented, which foreign keys lack an index.

• pythia impact T before any ALTER — every program that recompiles.
• pythia similar T_<NAME> and pythia ddl TABLE <NEIGHBOUR> — how this

house already builds tables: PK style, audit columns, tablespace, naming. Read .pythia/conventions.md and pythia conventions.

1. Ask what is the developer's (through pythia-spec): what is kept or

deleted, nullability of existing rows and the backfill value, retention, who writes the table (an API package, a trigger, an interface), identity column vs sequence when the house has no rule. Never invent a business default for a NOT NULL column.

1. Write one ordered script — reference/ddl-standards.md has the

template and the datatype rules:

• name every constraint (PK_, FK_, UK_, CK_ unless the house says

otherwise); a primary key on every table; an index on every FK column;

• text as VARCHAR2(n CHAR) — a Vietnamese character can take 3 bytes;

money as NUMBER(p,s), never FLOAT; DATE or TIMESTAMP by need;

• COMMENT ON TABLE and COMMENT ON COLUMN for every new table and

column: meaning, unit, allowed values, source. Vietnamese is fine here — COMMENT ... IS takes a literal only (no unistr), and pythia sends UTF-8 exactly; pythia doctor --db warns if the character set cannot hold it.

1. Lint it: pythia lint script.sql comments.sql (one run, so the

comments file counts) — missing comments, unnamed constraints, unindexed FKs, ADD ... NOT NULL without a default, byte-semantics text, missing house columns. Errors are fixed, not argued.

1. Land it with pythia-deploy (pythia deploy script.sql): every

statement previewed, one approval, run in order, stopped at the first failure. A single statement can go through pythia apply as usual. structural is deny by default — relay the refusal; the developer decides (pythia policy set structural confirm, or an autopilot lease naming structural).

1. Verify (pythia-verify): pythia cols T, pythia comments T (0

missing), pythia invalid against the baseline.

Changing a live table — expand, then contract

Big tables (millions of rows): ALTER TABLE ... ADD with a default is metadata-only, but MODIFY, index builds and backfills are not — ask about a window, and ONLINE index builds need Enterprise Edition. Partitioning and compression are separately licensed options: name that before proposing them.

Is rollback real?

Red Flags — STOP if you catch yourself thinking

When NOT to use this skill

• Changing code that reads the table → pythia-write / pythia-package.
• A slow query on an existing table → pythia-tune (an index is still

designed here once tuning asks for it).

• Data fixes (UPDATE/DELETE) → pythia-apply; they are data_dml.