Victoriametrics: option to disable PQL extensions

[belm0]

From MetricsQL docs:

Note that the functionality mentioned below doesn't work in PromQL, so it is impossible switching back to Prometheus after you start using it.

We value the flexibility to switch to another PQL implementation in the future, and would like to mitigate problems by disabling PQL extensions in our deployment. Unknowing query authors may use extensions without being aware (e.g. leaving period off of rate()).

[hagen1778]

Hi @belm0! MetricsQL is not an extension of PromQL, but a separate query language. It does its best in attempt to achieve backward compatibility with PromQL but some things like rate/irate functions are intentionally implemented in a different way. The reasoning and motivation for this can be found here https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/MetricsQL. So it is unlikely that ability to disable non-PromQL functions will ever appear.

[belm0]

Thank you. Do we agree that MetricsQL is a superset of PQL? Except for some small semantic differences noted in the docs, it must be so-- since easy migration of Prometheus query workloads is listed as a Victoria Metrics feature.

So for a PQL user, features outside of the intersection can said to be extensions of PQL. We can take an example from compilers like gcc, where flags are offered to limit extensions, gate experimental features, etc. These are desirable for various reasons, including users wanting to avoid vendor lock-in (whether intentional or unintentional) and maintain flexibility to chose different implementations in the future.

Regards,

[johnseekins]

You could put something like promxy in front of your VictoriaMetrics instance. That would limit users to only PromQL queries. Bit of a hack, but it would _work_.

[valyala]

This looks like a duplicate of https://github.com/VictoriaMetrics/VictoriaMetrics/issues/8

[belm0]

closing as duplicate, and I'll copy the useful parts of this issue

[valyala]

@belm0 , thanks for doing this!