I had difficulties parsing the description of the issue, I think eventually I got it, let me re-phrase it the way I understood it:

Problem 1:
The Audit plugin doesn't log CREATE PROCEDURE when audit event types are limited to QUERY_DDL and/or QUERY_DML, it only logs CREATE PROCEDURE when QUERY events are enabled.

Problem 2:
The Audit plugin documentation claims that CREATE PROCEDURE and such are not DDL.

I agree that "problem 2" is a valid complaint. Even if, on whatever reason, the Audit plugin is designed not to count CREATE PROCEDURE as an audit event of type QUERY_DDL, it doesn't mean that "they're not DDL". The KB should be more accurate and say that they are not logged along with other DDL statements, or whatever, and preferably explain why.

For the "problem 1", apparently the Audit plugin works as designed, or at least as documented. The fact that the Audit plugin intentionally doesn't consider CREATE PROCEDURE as QUERY_DDL is explicitly stated in the documentation, even if the wording is clumsy. I cannot determine whether it's a design flaw which needs to be fixed, as I don't know why it was decided to be done this way. Assigning to ralf.gebhardt@mariadb.com, hopefully he knows the reason.

At the same time, this exception by no means implies that it would be considered DML instead, neither does the documentation say so. Regardless of whether it counts as DDL in the Audit plugin world, CREATE PROCEDURE cannot possibly be DML.

This is so very "implementation defined", every DBMS does it differently. In the SQL standard there is no DML and DDL, there are

• SQL-schema statements — pretty much all CREATE/DROP statements are there
• SQL-data statements — cursor operations: DECLARE/OPEN/CLOSE/FETCH, SELECT, and all SQL-data change statements
• SQL-data change statements — insert/delete/update/truncate (sic!)
• SQL-transaction statements — START TRANSACTION, COMMIT, ROLLBACK, and savepoint statements
• SQL-control statements — CALL/RETURN
• SQL-session statements — SET ROLE/NAMES
• SQL-diagnostics statements — GET DIAGNOSTICS
• SQL-dynamic statements — PREPARE/EXECUTE/DEALLOCATE

We can define DDL as "SQL-schema statements" and DML as "SQL-data statements", that looks like a least controversial definition, avoids the need to decide per statement.

Of course, MariaDB extensions, like HANDLER, still needs to be categorized on a per statement basis.

We could also define DCL, TCL, and other TLAs based on this standard statement grouping

serg Within the Documentation Team, GeoffMontee and I have evaluated the definitions proposed.

ISO 9075-2:2016 identifies the following implementation-specific classifiers:

• SQL-schema statements
• SQL-data statements
• SQL-transaction statements
• SQL-control statements
• SQL-connection statements
• SQL-session statements
• SQL-diagnostics statements
• SQL-dynamic statements

We agree that for Documentation purposes, we would want to define:

• DDL as SQL-schema statements, as referenced in ISO 9075-2:2016
• DML as SQL-data statements, as referenced in ISO 9075-2:2016

We have additionally surveyed peer documentation practices by MySQL, PostgreSQL, Oracle database, and Microsoft SQL Server. The number of classifications they define within their documentation varies from the low end of defining only DDL and DML, to the high end of additionally defining SQL-control, SQL-session, and/or SQL-transaction. The proposed definitions for DDL and DML appear consistent with the practices of these other databases.

holyfoot, see above. For audit plugin, too,

QUERY_DDL should mean all statements from the standard "SQL-schema statements" group,
QUERY_DML should mean all statements from the standard "SQL-data statements" group,
QUERY_DCL should mean all statements from the standard "SQL-control statements" group,
QUERY_DML_NO_SELECT should mean all statements from the standard "SQL-data change statements" group,