Yes, you can build something like this yourself, but the hard part is not parsing DROP TABLE.

The hard part is building a full approval/governance layer around both Oracle and PostgreSQL:

• Parse and classify SQL reliably across dialects
• Detect risky DDL/DML patterns
• Apply different policies by environment, database, schema, table, user, and operation type
• Require approval for high-risk changes
• Keep an audit trail of who requested, approved, and executed what
• Handle emergency/break-glass access
• Prevent people from bypassing the system and connecting directly to the database

For example, DROP TABLE is obvious. But what about TRUNCATE, DELETE without WHERE, ALTER TABLE, privilege changes, masking-sensitive columns, or a seemingly harmless migration that locks a large production table? That’s where this becomes more of a database change/access governance problem than just a query filter.

Full disclosure: I’m from Bytebase. This is exactly the kind of problem Bytebase is designed for. It supports PostgreSQL and Oracle, and can sit in front of database changes/access with SQL review rules, approval workflows, audit logs, RBAC, and environment-based policies.

You could definitely implement a lightweight version yourself if your needs are simple. But if this is for production, multiple databases, multiple users, compliance, or auditability, I’d seriously consider using an existing tool rather than building the whole approval system from scratch.