Will Partial Evaluation support Built-in regex Functions？

[huntkalio]

https://www.openpolicyagent.org/docs/filtering/fragment say regex is unsupported builtin (for unknown values) now, Will there be support in the future? Because mysql have function REGEXP, we could use it 。
This is useful in many scenarios, such as regular expressions in AWS IAM like ”arn:aws:iam::111122223333:user/*”

[srenatus]

No, regex are not supported. They could yield different results, in some cases, because OPA uses golang's RE2, and MySQL does not. Sorry! It's crucial that the semantics don't change in the process of filtering data compared to usual Rego evals.

We haven't really thought about extension points in the filtering work, perhaps it would make sense to let people opt in, at least in their own OPA builds... 🤔

[huntkalio]

Even using matches("*", _) will result to

{
  "code": "evaluation_error",
  "message": "error(s) occurred while evaluating query",
  "errors": [
    {
      "code": "pe_fragment_error",
      "message": "both rhs and lhs non-scalar/non-ground"
    }
  ]
}

It's fine whether it appears in the filter or not. But this response seems incorrect.

[srenatus]

OK I've found a workaround that might be acceptable:

matches("*", x) if x != ""

that'll give you a

resource.name <> ''

[huntkalio]

ok，I will try it.

[huntkalio]

The filter result isn't wrong, is it? It should include any resource? 🤔

I think I'd try to capture the pattern '*' as "it exists" and would use

matches("*", _)

But it would need to not appear in your filters then, exactly. Let me play with the rego a bit.

Btw did you see open-policy-agent/opa#7995? I'm hoping to get this into the next release which is imminent.

I'm hoping to get this into the next release which is imminent. is ok! Thanks for the support.

[srenatus]

Also filed open-policy-agent/opa#7996 for the last surprise you had encountered there.