regexp_match skips first match when returning match

[Jefffrey]

Describe the bug

In some cases regexp_match will skip first and only match.

e.g. if pattern is foo and string to match is foo then should return single match foo. Currently returning empty array for the match (correctly finds there is a match, but doesn't return the match correctly).

To Reproduce

Example test in arrow-string/src/regexp.rs

    #[test]
    fn sandbox() {
        let array = StringArray::from(vec![Some("foo")]);
        let pattern = GenericStringArray::<i32>::from(vec![r"foo"]);
        let actual = regexp_match(&array, &pattern, None).unwrap();
        let result = actual.as_any().downcast_ref::<ListArray>().unwrap();
        let elem_builder: GenericStringBuilder<i32> = GenericStringBuilder::new();
        let mut expected_builder = ListBuilder::new(elem_builder);
        expected_builder.values().append_value("foo");
        expected_builder.append(true);
        let expected = expected_builder.finish();
        assert_eq!(&expected, result);
    }

Will panic with:

thread 'regexp::tests::sandbox' panicked at 'assertion failed: `(left == right)`
  left: `ListArray
[
  StringArray
[
  "foo",
],
]`,
 right: `ListArray
[
  StringArray
[
],
]`', arrow-string/src/regexp.rs:277:9

Can see the right (actual) has empty StringArray[] whereas expected contains the match: StringArray["foo"]

Expected behavior

Test should succeed.

Additional context

Seems its because by default skipping the first match in a capture group:

arrow-rs/arrow-string/src/regexp.rs

Lines 210 to 218 in 79518cf

	match re.captures(value) {
	Some(caps) => {
	for m in caps.iter().skip(1).flatten() {
	list_builder.values().append_value(m.as_str());
	}
	list_builder.append(true);
	}
	None => list_builder.append(false),
	}

Where in the test example above, caps has value:

[arrow-string/src/regexp.rs:212] &caps = Captures(
    {
        0: Some(
            "foo",
        ),
    },
)

Relevant regex doc: https://docs.rs/regex/latest/regex/struct.Regex.html#method.captures

Specifically:

Capture group 0 always corresponds to the entire match.

Original issue: apache/datafusion#5479

[tustvold]

I'm not sure if I'm missing something but foo is not a capture group? If you instead change the pattern to contain a capture group, e.g. (foo) it works correctly?

[Jefffrey]

If parity with Postgres is desired, then this would be considered a bug. Relevant extract:

If a match is found, and the pattern contains no parenthesized subexpressions, then the result is a single-element text array containing the substring matching the whole pattern

From: https://www.postgresql.org/docs/current/functions-matching.html

Also it might be somewhat confusing as returning a not-null value in the output ListArray indicates a match was found (else it would be null instead of a StringArray), but resultant StringArray itself is empty without the match. The behaviour seems somewhat inconsistent?

[Weijun-H]

I'm not sure if I'm missing something but foo is not a capture group? If you instead change the pattern to contain a capture group, e.g. (foo) it works correctly?

(foo) can work.

[tustvold]

If parity with Postgres is desired, then this would be considered a bug

Makes sense, we should probably update the function's docs to match

[tustvold]

label_issue.py automatically added labels {'arrow'} from #3807