tustvold commented on code in PR #1846:
URL: https://github.com/apache/arrow-rs/pull/1846#discussion_r895710960
##########
arrow/src/compute/kernels/comparison.rs:
##########
@@ -548,6 +548,89 @@ pub fn ilike_utf8_scalar<OffsetSize: OffsetSizeTrait>(
Ok(BooleanArray::from(data))
}
+/// Perform SQL `left NOT ILIKE right` operation on [`StringArray`] /
+/// [`LargeStringArray`].
+///
+/// See the documentation on [`like_utf8`] for more details.
+pub fn nilike_utf8<OffsetSize: OffsetSizeTrait>(
+ left: &GenericStringArray<OffsetSize>,
+ right: &GenericStringArray<OffsetSize>,
+) -> Result<BooleanArray> {
+ regex_like(left, right, true, |re_pattern| {
+ Regex::new(&format!("(?i)^{}$", re_pattern)).map_err(|e| {
+ ArrowError::ComputeError(format!(
+ "Unable to build regex from ILIKE pattern: {}",
+ e
+ ))
+ })
+ })
+}
+
+/// Perform SQL `left NOT ILIKE right` operation on [`StringArray`] /
+/// [`LargeStringArray`] and a scalar.
+///
+/// See the documentation on [`like_utf8`] for more details.
+pub fn nilike_utf8_scalar<OffsetSize: OffsetSizeTrait>(
Review Comment:
It occurs to me that we now have four methods `ilike_utf8_scalar`,
`nlike_utf8_scalar`, `like_utf8_scalar`, `nilike_utf8_scalar` where the only
difference appears to be an optional post-conversion on `left.value(i)`.
Perhaps we could refactor out the common logic into a function taking `F:
Fn(&str) -> Cow<'_, str>` or something?
##########
arrow/src/compute/kernels/comparison.rs:
##########
@@ -548,6 +548,89 @@ pub fn ilike_utf8_scalar<OffsetSize: OffsetSizeTrait>(
Ok(BooleanArray::from(data))
}
+/// Perform SQL `left NOT ILIKE right` operation on [`StringArray`] /
+/// [`LargeStringArray`].
+///
+/// See the documentation on [`like_utf8`] for more details.
+pub fn nilike_utf8<OffsetSize: OffsetSizeTrait>(
+ left: &GenericStringArray<OffsetSize>,
+ right: &GenericStringArray<OffsetSize>,
+) -> Result<BooleanArray> {
+ regex_like(left, right, true, |re_pattern| {
+ Regex::new(&format!("(?i)^{}$", re_pattern)).map_err(|e| {
+ ArrowError::ComputeError(format!(
+ "Unable to build regex from ILIKE pattern: {}",
+ e
+ ))
+ })
+ })
+}
+
+/// Perform SQL `left NOT ILIKE right` operation on [`StringArray`] /
+/// [`LargeStringArray`] and a scalar.
+///
+/// See the documentation on [`like_utf8`] for more details.
+pub fn nilike_utf8_scalar<OffsetSize: OffsetSizeTrait>(
+ left: &GenericStringArray<OffsetSize>,
+ right: &str,
+) -> Result<BooleanArray> {
+ let null_bit_buffer = left.data().null_buffer().cloned();
+ let mut result = BooleanBufferBuilder::new(left.len());
+
+ if !right.contains(is_like_pattern) {
+ // fast path, can use equals
+ for i in 0..left.len() {
+ result.append(left.value(i) != right);
+ }
+ } else if right.ends_with('%') && !right[..right.len() -
1].contains(is_like_pattern)
+ {
+ // fast path, can use ends_with
+ for i in 0..left.len() {
+ result.append(
+ !left
+ .value(i)
+ .to_uppercase()
Review Comment:
Given this allocates a new string, I wonder how much faster this fast path
actually is? Do you have some benchmark results?
##########
arrow/src/compute/kernels/comparison.rs:
##########
@@ -3984,6 +4067,60 @@ mod tests {
vec![false, true, false, false]
);
+ test_utf8!(
Review Comment:
Maybe a test of non-ASCII characters, e.g. Â â or something
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
