Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow fast DDL vs DML recognition #4

Open
jaypipes opened this issue Jan 22, 2018 · 0 comments
Open

Allow fast DDL vs DML recognition #4

jaypipes opened this issue Jan 22, 2018 · 0 comments
Milestone

Comments

@jaypipes
Copy link
Owner

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.

@jaypipes jaypipes added this to the 0.3 milestone Jun 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant