Thanks, that's great! Some high-level comments first:

• for the SQLQueryError, this looks quite similar to ExpectedErrors. Do we really need this class or can we combine these classes?
• for statements like UPDATE, DELETE, and ALTER TABLE, do you think we can use and extend the generator classes rather than implementing the logic in the DQE oracle?

Regarding the SQLQueryError and ExpectedErrors classes, while they do share some surface-level similarities, I think it's important to highlight that their purposes and usage patterns are quite different in practice:

• SQLQueryError is specifically designed to represent actual errors returned by the database, with structured fields like error level, code, and message. It plays a crucial role in DQE logic to distinguish between different types of errors returned by statements such as UPDATE, SELECT, or DELETE.
• On the other hand, ExpectedErrors serves as a declarative mechanism for defining acceptable errors during testing, primarily relying on substring or regex-based matching. It does not require the same level of structural detail as SQLQueryError.

Given these differences, merging them into a single class could lead to confusion, increased coupling, and reduced clarity in terms of responsibility separation. I believe keeping them separate helps maintain a clean architecture and supports better extensibility in the future.

That said, if you have any alternative suggestions or design ideas on how we can better organize this part of the code, I’d be more than happy to discuss them further. Thanks again for your thoughtful feedback! @mrigger @JensonSung