# Add DDL Triggers Support in MySQL

**Status:** Draft  
**Roadmap Section:** Developer/DBA Experience  
**Primary Contact:** Praveenkumar Hulakund  
**Email:** praveenkumar.hulakund@oracle.com  
**Company / Organization:** Oracle  
**Role / Team:** TBD  
**Additional Authors / Contributors:** None listed  
**Date:** 2026-05-07  
**Target Release:** TBD  
**Related References:** https://bugs.mysql.com/bug.php?id=117802

> This template is a guide for writing clear and reviewable technical design proposals. It does not replace broader contribution guidelines, engineering standards, or release processes.

---

## 1. High-Level Description

### Executive Summary

This WorkLog proposes adding DDL triggers to MySQL.

DDL triggers are database triggers that execute automatically when a DDL statement is executed. Unlike existing MySQL triggers, which fire on table-level DML events such as INSERT, UPDATE, and DELETE, DDL triggers would fire on schema/object changes such as CREATE, ALTER, DROP and RENAME.

The feature would allow users to audit, restrict, validate, or react to schema changes directly inside MySQL. Database administrators and application teams often need to know when schema changes happen, who performed them, and what object was affected.

The feature should allow users to:

  1. Create triggers for DDL events.
  2. Execute trigger logic before or after a DDL statement.
  3. Audit schema changes into user-defined tables.
  4. Block risky DDL operations.

Similar feature is already available in the PostgreSQL, Oracle, and SQL Server.

### User / Developer Stories

Use Case 1: Audit all schema changes
A DBA wants to record every schema change in an audit table.

CREATE TABLE admin.ddl_audit_log (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
user_name VARCHAR(255),
event_name VARCHAR(64),
object_schema VARCHAR(255),
object_name VARCHAR(255),
object_type VARCHAR(64),
event_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP
); 

CREATE TRIGGER audit_schema_changes
AFTER DDL ON DATABASE
FOR EACH STATEMENT
BEGIN
INSERT INTO admin.ddl_audit_log (...);
END;
 

Benefit:

Provides native schema-change visibility without external log parsing. 

Use Case 2: Block accidental DROP operations
A production schema should not allow direct DROP operations.
 
CREATE TRIGGER prevent_drop_in_prod
BEFORE DROP ON SCHEMA
FOR EACH STATEMENT
BEGIN
  SIGNAL SQLSTATE '45000'
    SET MESSAGE_TEXT = 'DROP operations are not allowed in production schema';
END;

Benefit:
Prevents accidental or unauthorized object deletion.

### Scope

**In Scope**

_TBD_

**Out of Scope / Limitations**

_TBD_

### References

_TBD_

---

## 2. Requirements

Use precise wording such as **MUST**, **SHOULD**, and **MAY** where appropriate.

### Functional Requirements

- FR1. The proposal MUST describe the intended user-visible behavior.
- FR2. The proposal SHOULD identify compatibility and observability impacts.

### Non-Functional Requirements

- NFR1. The proposal SHOULD be concise enough for broad community review.
- NFR2. The template MAY include deeper implementation detail when needed.

---

## 3. Impact Checklist

Use this section as a quick summary of which interfaces or subsystems are affected by the proposal. The checklist does **not** replace the detailed specification in the sections below.

- [ ] No items selected yet

---

## 4. High-Level Specification

### Summary of the Approach

Use a short public template with a clarified Impact Checklist, then keep a detailed User Interface section where reviewers need precision.

### User Interface

### Configuration / Knobs — New configuration clauses or options

_TBD_

### Configuration / Knobs — New system variables or command-line options

_TBD_

### Configuration / Knobs — New command-line options for utilities

_TBD_

### Configuration / Knobs — New UDFs or similar extension points

_TBD_

### New Statements

_TBD_

### Observability

_TBD_

### User Procedure

_TBD_

### Security Context

_TBD_

### Compatibility and Behavior Change

_TBD_

---

## 5. Low-Level Design

### Block Diagram

_TBD_

### Interface Specification

_TBD_

### Design / Implementation Steps

_TBD_

---

## 6. QA Notes

_TBD_