Julius Volz

@bwplotka It still seems like a too specific code change to me that is not needed in Prometheus itself, but that we then would have to maintain and not break...

Yeah, @beorn7 (who is sitting next to me) essentially said the same and recommended talking to @roidelapluie about this.

If we do pagination at all, maybe an approach in the middle would be a good compromise: do it pagination-based, but track the generation ID of the current rule set...

> I am very confident that we should not introduce an embedded expression language into PromQL if we can avoid it. > > I would be very happy to hear...

@qinxx108 Prometheus can reload its configuration and rule files during runtime, so I think assigning a unique ID to each rule in memory would not be sufficient, since you also...

@alexandreh2ag Thanks for suggesting this! I do agree with @roidelapluie that it doesn't seem worth the extra introduced complexity yet, given that this is the first time a request for...

The issue is really just that the table output is really dumb and doesn't do any escaping (besides automatic HTML safety stuff): https://github.com/prometheus/prometheus/blob/dfa5cd55db548b8f1355b5aabb7cf869491272a2/web/ui/react-app/src/pages/graph/SeriesName.tsx#L37 The rest seems to work fine.

@roidelapluie That's a different issue. Double-quoted strings in PromQL interpret escape sequences starting with `\`, and `\.` is not a valid Go string escape sequence. Try backticks for no interpretation...

@brancz Hm yeah. Optimally the autocompletion would be able to understand the string context it's in (double-quoted string vs. backtick-quoted) and escape any inserted label values accordingly, if necessary.

@roidelapluie Btw., regarding our string interpretation: https://prometheus.io/docs/prometheus/latest/querying/basics/#string-literals