test: cover regexp_like multiline flag

[nanookclaw]

Which issue does this PR close?

• Relates to PostgreSQL compatibility: regexp_like should honor PostgreSQL multiline flag m #22268.

Rationale for this change

The issue documents a PostgreSQL compatibility expectation for regexp_like(E'a\nb', '^b', 'm'): with the multiline flag, ^ should match after a newline. Current main already returns the expected result for the reported SQL, so this PR adds focused regression coverage to keep that behavior from drifting.

What changes are included in this PR?

This adds regexp_like tests for the multiline m flag in the SQL logic test suite and in the Rust unit tests for the scalar, array/scalar, and array/array execution paths. The adjacent no-flags SQL case remains false, documenting that the new behavior is specifically tied to m.

Are these changes tested?

Yes:

• cargo fmt --all --check
• git diff --check
• cargo test -p datafusion-functions --lib regexp_like
• cargo test -p datafusion-sqllogictest --test sqllogictests -- regexp_like

Are there any user-facing changes?

No. This is regression coverage for existing behavior.

[Jefffrey]

So was the original issue a false report?

[nanookclaw]

It looks stale on current main rather than a code change needed in this PR. Before opening this I checked the reported query against current main and it already returned PostgreSQL's expected result (true for regexp_like(E'a\nb', '^b', 'm')).

So this PR is intentionally regression coverage only: it locks the multiline m behavior in both SQL logic tests and the Rust scalar/array paths. I did not trace the exact commit that fixed the originally reported mismatch; it may have been corrected by another regex-path change between #22268 being filed and this PR.

If coverage-only is not useful here, I'm fine closing it.

[Jefffrey]

I would like to understand the original issue more, especially since the related file hasn't seen a change in 2 months 🤔

https://github.com/apache/datafusion/blob/main/datafusion/functions/src/regex/regexplike.rs

[nanookclaw]

I dug into this more after your question, and I agree the original split-out issue looks questionable.

What I can verify:

• The umbrella report was against DataFusion 53.1.0 / commit 1ab146ad6cc119c7656ae1def75fd40697e5f94a.
• datafusion/functions/src/regex/regexplike.rs at that commit already passed non-g flags through as inline regex flags ((?m)), same as current main.
• The regexp sqllogictest file at that commit already had multiline regex coverage around the regex operators, and regexp_like(..., 'm') flag coverage existed too.
• I do not see a later change to regexplike.rs that would explain the repro becoming fixed.

So my current read is: #22268 was probably a false-positive split from the umbrella issue, or at least not a live regexp_like implementation bug by the time this PR was opened. This PR is only regression coverage for the reported PostgreSQL-compatible behavior. If coverage-only is not useful here, I’m fine closing it.

[Jefffrey]

I'm fine with adding test coverage if we don't already have the multiline cases; could we just add only the SLTs however? We prefer having SLTs over the Rust test cases where possible

[nanookclaw]

Updated to keep this as SLT-only coverage: the Rust tests have been removed, and the PR now only adds the two regexp_like SLT cases for multiline flag behavior.

Validation run locally:

• cargo fmt --all --check
• cargo test --profile=ci --test sqllogictests -- regexp_like.slt
• cargo test -p datafusion-functions --lib regex::regexplike

[Jefffrey]

Thanks @nanookclaw