You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
There is now a
sqltoast::parse_options_t
switch that disables the construction of thesqltoast::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 asqltoast::parse_options_t
field to trigger short-circuiting parsing when the caller is only interested in the category of statement or subcategory.The text was updated successfully, but these errors were encountered: