Description
There is now a sqltoast::parse_options_t switch that disables the construction of the sqltoast::statement objects if the caller doesn't want or need these objects.
One reason the caller may not want the objects is because they actually aren't attempting to execute operations using the information in the objects but rather need a simple top-level routing parser that can indicate the "category" of SQL statement that has been sent. For example, a top-level proxy/router might want to simply know whether the successfully parsed statement is a DDL statement (CREATE, DROP, SET, etc) or a DML statement (INSERT, SELECT, DELETE, UPDATE etc).
Further, such a proxy might want to know a sub-category of the DDL or DML statement, for instance to direct read operations to different backing endpoints than write operations.
In these use cases, there's no point in constructing the sqltoast::statement objects or even validating much more than the rough tokens corresponding to the SQL statement are valid. Instead, there should be a sqltoast::parse_options_t field to trigger short-circuiting parsing when the caller is only interested in the category of statement or subcategory.