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

[TraceQL Enhancement] Quoted attribute names #2805

Closed
mdisibio opened this issue Aug 18, 2023 · 0 comments · Fixed by #3004
Closed

[TraceQL Enhancement] Quoted attribute names #2805

mdisibio opened this issue Aug 18, 2023 · 0 comments · Fixed by #3004
Labels

Comments

@mdisibio
Copy link
Contributor

Currently you can access an attribute in TraceQL with a dot (.) and then typing the attribute name: .value. All characters after the dot and up to the next breaking character are considered part of the attribute name. Examples of breaking characters include things like =, space, etc (full list here). This allows queries like .value=5 to work as expected. However it also prevents using attributes with these special characters in the name. Attribute names can contain any UTF-8 character and TraceQL should support it.

We can solve this with a new optional quoted syntax for attribute names, like this: ."value with a space". All characters between the quotes will be considered part of the attribute name, including all breaking characters that were previously not allowed. Backslashes can be used to escape and embed quotes and the backslash itself ."name with a quote \" and a slash \\". We think this solution solves 100% of the attribute naming issues.

Quoted names can be combined with scopes: resource."name" span."name". The quotes only wrap the name portion to change the way it is parsed.

Additional notes

  1. All previous attribute name parsing still remains. The default syntax .name is simple and readable and we want to keep it.
  2. The only required escape sequences are \" (double quote) and \\ backslash. But this provides a good framework for adding more escape sequences in the future if we think of them.
  3. This quoted approach should mesh well with other how other languages will support non-standard characters (i.e. PromQL)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants