-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
sql,ast: better redact support for statements #55862
Comments
Hi @ajwerner, I've guessed the C-ategory of your issue and suitably labeled it. Please re-label if inaccurate. While you're here, please consider adding an A- label to help keep our repository tidy. 🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is otan. |
We have marked this issue as stale because it has been inactive for |
Is your feature request related to a problem? Please describe.
Currently the cockroach code generates an anonymized string for statements by formatting the AST to hide all constants. This ends up preserving relation names but losing information about columns making it hard to unpack the structure of a statement.
cockroach/pkg/ccl/backupccl/restore_job.go
Line 1805 in 3d920ee
Another issue is that we pass this anonymized statement around as a string. That means that if we log it or include it in an error without remembering to wrap it in
redact.Safe
orlog.Safe
then it will be redacted. Ideally we'd be able to get nice redacted statement structure that might even be able to preserve more of the structure than we do today.Describe the solution you'd like
I see several options with some tradeoffs. We may want to do all of them. The details are intentionally vague.
redact.SafeMessage
or something like it on all of the ast statements (or even add it to the interface). This would eliminate the need to calllog.Safe
but doesn't make the story around constants any better.SafePrinter
that can remap constants to hashes as appropriate or something like thatSafePrinter
that might have access to column identifiers and table identifiers. This might be better served as an AST transformation pre-processing step rather than as something that happens during formatting.Epic: CRDB-6668
Jira issue: CRDB-3621
The text was updated successfully, but these errors were encountered: