SQL changes and approval

Read the risk before the SQL

DDL, or data definition language, changes a database's structure (CREATE, ALTER, DROP, TRUNCATE). DML, or data manipulation language, changes rows (INSERT, UPDATE, DELETE, MERGE). A wrong SELECT wastes time, while an unbounded UPDATE or DROP changes or removes data. Create and insert in a dev database are cheap to redo. Changes to an existing shared table need a proposal and human approval.

Bruin's strategy: ddl describes a table from its columns without a query body. full_refresh_restricted protects a table from a rebuild that would replace all of its rows. These settings add safety checks, but database permissions are still the strongest protection.

Your task

Write docs/operation-policy.md with a table covering SELECT, CREATE, INSERT, ALTER, MERGE, UPDATE, DELETE, TRUNCATE, and DROP. Include what happens if each is wrong, whether it is reversible, and whether an agent may run it. Do not run the statements.

Check your understanding

• Why is MERGE higher risk than a SELECT?
• What does full_refresh_restricted protect against?
• Which changes may be autonomous in a dev schema?

Do it with your agent

Say next lesson, classify the operations yourself, then say review my work. Do not execute the statements while completing this lesson.

Rubric

• Covers all nine named operations exactly once.
• Marks DROP, DELETE, and TRUNCATE as data-loss risks requiring no autonomous execution.
• Marks dev CREATE/INSERT as bounded and redoable, and in-place ALTER/MERGE/UPDATE as proposal-only.