test: add IN list slt coverage for temporal, Decimal128 and Interval types by alamb · Pull Request #23875 · apache/datafusion

alamb · 2026-07-24T21:47:52Z

Which issue does this PR close?

Part of SQL / slt coverage for IN lists #23307.

Rationale for this change

IN lists over temporal, Decimal128 and Interval columns had no SQL level coverage at all, and the specializations being added in #23014 route those types onto new code paths.

What changes are included in this PR?

Adds in_list.slt coverage for Date32, Date64, Time32(Second), Time64(Nanosecond), Timestamp(Nanosecond, None), Timestamp(Second, "UTC"), Duration(Second), Decimal128 and Interval(MonthDayNano)

Are these changes tested?

This PR is only tests; they pass on main and against the head of #23014.

Are there any user-facing changes?

No.

codecov-commenter · 2026-07-24T22:14:13Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.65%. Comparing base (88365dd) to head (a3fd8f3).
⚠️ Report is 39 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #23875      +/-   ##
==========================================
- Coverage   80.65%   80.65%   -0.01%     
==========================================
  Files        1093     1093              
  Lines      371619   371619              
  Branches   371619   371619              
==========================================
- Hits       299730   299721       -9     
- Misses      53993    54001       +8     
- Partials    17896    17897       +1

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

…types Part of apache#23307. Adds sqllogictest coverage for IN lists over Date32, Date64, Time32, Time64, Timestamp (with and without a timezone), Duration, Decimal128 and Interval(MonthDayNano), none of which had any SQL level coverage. Also adds a 17 element Int8/UInt8 list and a 9 element Float16 list so the bitmap specialization stays covered as shorter lists gain their own specializations. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

nuno-faria

Thanks @alamb, LGTM, I leave some minor suggestions below.

Also, according to the code coverage there are some uncovered IN cases with larger lists, like INT32. I don't know if it is important.

nuno-faria · 2026-07-29T20:44:01Z

+CREATE TABLE in_list_temporal AS
+SELECT
+  label,
+  arrow_cast(arrow_cast(value, 'Int32'), 'Date32')                     AS d32,
+  arrow_cast(arrow_cast(value, 'Int64'), 'Date64')                     AS d64,
+  arrow_cast(arrow_cast(value, 'Int32'), 'Time32(Second)')             AS t32s,
+  arrow_cast(arrow_cast(value, 'Int64'), 'Time64(Nanosecond)')         AS t64ns,
+  arrow_cast(arrow_cast(value, 'Int64'), 'Timestamp(Nanosecond, None)') AS ts_ns,
+  arrow_cast(arrow_cast(value, 'Int64'), 'Timestamp(Second, Some("UTC"))') AS ts_s_utc,
+  arrow_cast(arrow_cast(value, 'Int64'), 'Duration(Second)')           AS dur_s


nit: The aliases are not aligned, if that was the idea 😄.

nuno-faria · 2026-07-29T20:47:30Z

+  d32      IN (arrow_cast(arrow_cast(3, 'Int32'), 'Date32'), arrow_cast(arrow_cast(4, 'Int32'), 'Date32'), arrow_cast(arrow_cast(5, 'Int32'), 'Date32'), arrow_cast(arrow_cast(11, 'Int32'), 'Date32')),
+  d64      IN (arrow_cast(arrow_cast(3, 'Int64'), 'Date64'), arrow_cast(arrow_cast(4, 'Int64'), 'Date64'), arrow_cast(arrow_cast(5, 'Int64'), 'Date64'), arrow_cast(arrow_cast(11, 'Int64'), 'Date64')),
+  t32s     IN (arrow_cast(arrow_cast(3, 'Int32'), 'Time32(Second)'), arrow_cast(arrow_cast(4, 'Int32'), 'Time32(Second)'), arrow_cast(arrow_cast(5, 'Int32'), 'Time32(Second)'), arrow_cast(arrow_cast(11, 'Int32'), 'Time32(Second)')),
+  t64ns    IN (arrow_cast(arrow_cast(3, 'Int64'), 'Time64(Nanosecond)'), arrow_cast(arrow_cast(4, 'Int64'), 'Time64(Nanosecond)'), arrow_cast(arrow_cast(5, 'Int64'), 'Time64(Nanosecond)'), arrow_cast(arrow_cast(11, 'Int64'), 'Time64(Nanosecond)')),
+  ts_ns    IN (arrow_cast(arrow_cast(3, 'Int64'), 'Timestamp(Nanosecond, None)'), arrow_cast(arrow_cast(4, 'Int64'), 'Timestamp(Nanosecond, None)'), arrow_cast(arrow_cast(5, 'Int64'), 'Timestamp(Nanosecond, None)'), arrow_cast(arrow_cast(11, 'Int64'), 'Timestamp(Nanosecond, None)')),
+  ts_s_utc IN (arrow_cast(arrow_cast(3, 'Int64'), 'Timestamp(Second, Some("UTC"))'), arrow_cast(arrow_cast(4, 'Int64'), 'Timestamp(Second, Some("UTC"))'), arrow_cast(arrow_cast(5, 'Int64'), 'Timestamp(Second, Some("UTC"))'), arrow_cast(arrow_cast(11, 'Int64'), 'Timestamp(Second, Some("UTC"))')),
+  dur_s    IN (arrow_cast(arrow_cast(3, 'Int64'), 'Duration(Second)'), arrow_cast(arrow_cast(4, 'Int64'), 'Duration(Second)'), arrow_cast(arrow_cast(5, 'Int64'), 'Duration(Second)'), arrow_cast(arrow_cast(11, 'Int64'), 'Duration(Second)'))


In this test and the others, I don't think the double arrow_cast is needed, only for Time32:

> select arrow_cast(3, 'Date32'); +-------------------------------------+ | arrow_cast(Int64(3),Utf8("Date32")) | +-------------------------------------+ | 1970-01-04 | +-------------------------------------+ > select arrow_cast(3, 'Time32'); Execution error: Unsupported type 'Time32'. Must be a supported arrow type name such as 'Int32' or 'Timestamp(ns)'. Error finding next token

nuno-faria · 2026-07-29T20:49:19Z

+####
+## Decimal128 IN List Specializations
+####
+
+statement ok
+CREATE TABLE in_list_wide AS
+SELECT * FROM (VALUES
+  ('match', arrow_cast(11, 'Decimal128(10, 2)'), INTERVAL '11 months'),
+  ('no_match', arrow_cast(7, 'Decimal128(10, 2)'), INTERVAL '7 months'),
+  ('nulls', NULL, NULL)
+) AS t(label, d128, imdn);
+
+query TT
+SELECT arrow_typeof(d128), arrow_typeof(imdn) FROM in_list_wide LIMIT 1
+----
+Decimal128(10, 2) Interval(MonthDayNano)


Should Decimal128 and INTERVAL maybe be split into different tests?

github-actions Bot added the sqllogictest SQL Logic Tests (.slt) label Jul 24, 2026

alamb force-pushed the alamb/in-list-slt-temporal-decimal branch from 6d501e6 to a3fd8f3 Compare July 26, 2026 16:06

alamb marked this pull request as ready for review July 26, 2026 16:07

nuno-faria approved these changes Jul 29, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

test: add IN list slt coverage for temporal, Decimal128 and Interval types - #23875

test: add IN list slt coverage for temporal, Decimal128 and Interval types#23875
alamb wants to merge 1 commit into
apache:mainfrom
alamb:alamb/in-list-slt-temporal-decimal

alamb commented Jul 24, 2026 •

edited

Loading

Uh oh!

codecov-commenter commented Jul 24, 2026 •

edited

Loading

Uh oh!

nuno-faria left a comment

Uh oh!

nuno-faria Jul 29, 2026

Uh oh!

nuno-faria Jul 29, 2026

Uh oh!

nuno-faria Jul 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

alamb commented Jul 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Which issue does this PR close?

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

Uh oh!

codecov-commenter commented Jul 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

nuno-faria left a comment

Choose a reason for hiding this comment

Uh oh!

nuno-faria Jul 29, 2026

Choose a reason for hiding this comment

Uh oh!

nuno-faria Jul 29, 2026

Choose a reason for hiding this comment

Uh oh!

nuno-faria Jul 29, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

alamb commented Jul 24, 2026 •

edited

Loading

codecov-commenter commented Jul 24, 2026 •

edited

Loading