feat(like): support LIKE over Binary arrays with byte semantics

[moshap-firebolt]

Summary

LIKE was restricted to Utf8 inputs — Like::return_dtype rejected Binary haystacks. But SQL LIKE over binary/bytea is well defined as a byte-wise match, and the matcher already runs over the haystack bytes. This adds LIKE support for Binary arrays with byte semantics.

Changes

• Like::return_dtype accepts Binary input for case-sensitive LIKE. ILIKE over Binary is still rejected, since case folding is only well defined over text.
• LikePattern regex fallback compiles with .unicode(false) when the haystack is Binary, so _/. match a single byte and %/.* span arbitrary bytes (including invalid UTF-8). Utf8 haystacks keep Unicode codepoint semantics — unchanged. The literal fast paths (Eq/StartsWith/EndsWith/Contains) were already byte-based.

Semantics

For a multi-byte haystack aЖb (Ж = 2 bytes):

pattern	Utf8 (codepoint)	Binary (byte)
a_b	match	no match
a__b	no match	match

% and the literal patterns match byte-for-byte on Binary, including across invalid-UTF-8 byte sequences.

Tests

• test_like_binary_byte_semantics — covers the byte-vs-codepoint distinction on multi-byte and invalid-UTF-8 data.
• test_ilike_over_binary_is_rejected — asserts ILIKE over Binary errors.
• All existing Utf8 LIKE/ILIKE tests continue to pass (no behavior change for Utf8).

[codspeed-hq]

Merging this PR will improve performance by 12.87%

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

⚡ 2 improved benchmarks
✅ 1954 untouched benchmarks
⏩ 517 skipped benchmarks¹

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
⚡	WallTime	words_gather_scalar[65536]	9.4 µs	8.2 µs	+14.04%
⚡	Simulation	compress_fsst[(500, 64, 8)]	585.9 µs	524.5 µs	+11.71%

Tip

Curious why this is faster? Comment @codspeedbot explain why this is faster on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing like-on-binary (721b719) with develop (b81420e)}

Footnotes

1. 517 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[connortsui20]

Thanks for the PR!

This causes an issue with how we rewrite LIKE, which assumes that its input is only UTF8.

vortex/vortex-array/src/stats/rewrite/builtins.rs

Lines 331 to 383 in b81420e

	struct LikeStatsRewrite;
	impl StatsRewriteRule for LikeStatsRewrite {
	fn scalar_fn_id(&self) -> ScalarFnId {
	Like.id()
	}
	fn falsify(
	&self,
	expr: &BoundExpression,
	ctx: &StatsRewriteCtx<'_>,
	) -> VortexResult<Option<BoundExpression>> {
	let like_options = expr.as_::<Like>();
	if like_options.negated || like_options.case_insensitive {
	return Ok(None);
	}
	let Some(pattern) = expr.child(1).as_opt::<Literal>() else {
	return Ok(None);
	};
	let Some(pattern) = pattern.as_utf8().value() else {
	return Ok(None);
	};
	let source = expr.child(0);
	Ok(match LikeVariant::from_str(pattern) {
	Some(LikeVariant::Exact(text)) => {
	min(source, ctx)
	.zip(max(source, ctx))
	.map(|(source_min, source_max)| {
	or(
	gt(source_min, lit(text.as_ref())),
	lt(source_max, lit(text.as_ref())),
	)
	})
	}
	Some(LikeVariant::Prefix(prefix)) => {
	let Some(successor) = prefix.to_string().increment().ok() else {
	return Ok(None);
	};
	min(source, ctx)
	.zip(max(source, ctx))
	.map(|(source_min, source_max)| {
	or(
	gt_eq(source_min, lit(successor)),
	lt(source_max, lit(prefix.as_ref())),
	)
	})
	}
	None => None,
	})
	}
	}

This approximately translates the LIKE to min > UTF8_LITERAL OR max < UTF8_LITERAL, where min and max are stats with the same dtype as the array/column. So once we allow binary columns as input to LIKE, we will try to compare a binary scalar (min/max) with a Utf8 literal scalar.

I think that there are a few possible solutions here, and to be honest neither of them seem the most ideal:

• We could just not use stats rewriting / pruning for binary LIKE, and this is probably the simplest thing
• We could coerce the Utf8 pattern into Binary when we see this pattern, and then the comparison comes for free (we are trying to move away from implicit coercions in Vortex)
• I also thought about requiring exact-typed patterns (we could say that you must prefix a LIKE on a binary with a b, so col_a LIKE b"prefix%", but that is a larger change.

Interested in what you are thinking?

[joseph-isaacs]

can this take a struct of options

[joseph-isaacs]

is byte_mode ascii mode?