What problem does it solve? Dropping or renaming MariaDB accounts has non-obvious behaviors that cause production surprises: dropped users keep working on active connections, owned objects and granted privileges are never cascaded, and views or routines are left with dangling DEFINER references. This Skill encodes those MariaDB-specific semantics so generated or reviewed account-teardown SQL is correct. ## Core Features & Use Cases - DROP USER semantics: Covers multi-account comma-separated drops, IF EXISTS turning missing-user errors into notes, the active-connections warning, and the required CREATE USER or mysql-database DELETE privilege. - No-cascade awareness: Explains that owned objects stay ownerless, privileges granted by the dropped user to others survive, and DEFINER objects must be re-pointed before the drop. - RENAME USER behavior: Documents privilege preservation across renames, host-part changes, partial-success error semantics, and the absence of any active-session check. - Use Case: When writing an idempotent cleanup script that decommissions service accounts, generate DROP USER IF EXISTS 'svc_batch'@'%', 'svc_report'@'%'; plus KILL CONNECTION statements for live sessions instead of one failing statement per account. ## Quick Start Ask the AI to write or review a MariaDB DROP USER or RENAME USER statement for your account cleanup scenario.
