-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
go/vt/sqlparser: statement serialized incorrectly #797
Comments
sougou
added a commit
that referenced
this issue
Aug 4, 2015
Fix for issue #797. Names that used keywords were not always getting back-quoted correctly during codegen. This is a comprehensive fix that covers all such possible cases.
systay
pushed a commit
to planetscale/vitess
that referenced
this issue
Aug 19, 2022
…essio#949) * Linter: `go fmt` a comment Signed-off-by: Patrick Reynolds <[email protected]> * Stop marking unnormalized stmts as `<error>` In the first draft of Insights, we unconditionally reported `<error>` as the normalized SQL statement for any reported statement that had an error. But that was too limiting, and we wanted to report SQL statements for errors any time we were reasonably confident they didn't have PII in them. So in 0b35306, we introduced `LogStats.IsNormalized` to indicate that a statement had been normalized successfully. We successfully applied `IsNormalized` to pass along real SQL statements with errors, if those statements had been normalized. Unfortunately, we overdid it and replaced all un-normalized statements with `<error>` whether or not the statement's execution had caused an error! It turns out lots of statements that aren't errors, also aren't normalized. @rafer found the two functions that control that, in vitessio#797. This commit fixes all that. Now we pass a SQL statement in all cases that we know to be normalized, as well as those that we know did not cause an error. We only send `<error>` for statements that are both un-normalized _and_ an error, which was the intent all along. Fixes vitessio#797. Signed-off-by: Patrick Reynolds <[email protected]> * Add some tests Signed-off-by: Patrick Reynolds <[email protected]> * Send raw SQL even if the query wasn't normalized If the user asks for raw queries, we should send them whether or not the queries got normalized. There's no leak or privacy violation once they opt into raw queries. There are two kinds of queries that aren't normalized, and we want raw SQL for both: - statements that don't need to be normalized, like `BEGIN`, or `ROLLBACK` - syntax errors, for which having raw SQL is useful for debugging Signed-off-by: Patrick Reynolds <[email protected]> Signed-off-by: Patrick Reynolds <[email protected]> Signed-off-by: Dirkjan Bussink <[email protected]> Co-authored-by: Dirkjan Bussink <[email protected]>
dbussink
added a commit
that referenced
this issue
Jan 30, 2023
* Linter: `go fmt` a comment Signed-off-by: Patrick Reynolds <[email protected]> * Stop marking unnormalized stmts as `<error>` In the first draft of Insights, we unconditionally reported `<error>` as the normalized SQL statement for any reported statement that had an error. But that was too limiting, and we wanted to report SQL statements for errors any time we were reasonably confident they didn't have PII in them. So in 0b35306, we introduced `LogStats.IsNormalized` to indicate that a statement had been normalized successfully. We successfully applied `IsNormalized` to pass along real SQL statements with errors, if those statements had been normalized. Unfortunately, we overdid it and replaced all un-normalized statements with `<error>` whether or not the statement's execution had caused an error! It turns out lots of statements that aren't errors, also aren't normalized. @rafer found the two functions that control that, in #797. This commit fixes all that. Now we pass a SQL statement in all cases that we know to be normalized, as well as those that we know did not cause an error. We only send `<error>` for statements that are both un-normalized _and_ an error, which was the intent all along. Fixes #797. Signed-off-by: Patrick Reynolds <[email protected]> * Add some tests Signed-off-by: Patrick Reynolds <[email protected]> * Send raw SQL even if the query wasn't normalized If the user asks for raw queries, we should send them whether or not the queries got normalized. There's no leak or privacy violation once they opt into raw queries. There are two kinds of queries that aren't normalized, and we want raw SQL for both: - statements that don't need to be normalized, like `BEGIN`, or `ROLLBACK` - syntax errors, for which having raw SQL is useful for debugging Signed-off-by: Patrick Reynolds <[email protected]> Signed-off-by: Patrick Reynolds <[email protected]> Signed-off-by: Dirkjan Bussink <[email protected]> Co-authored-by: Dirkjan Bussink <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The following program fails:
on commit 27bdc06
The text was updated successfully, but these errors were encountered: