Skip to content

Change extension dtype nullability without validating again - #11012

Merged
connortsui20 merged 3 commits into
developfrom
ct/ext-types/dtype-invariants
Nov 2, 2026
Merged

connortsui20 merged 3 commits into
developfrom
ct/ext-types/dtype-invariants

Conversation

@connortsui20

@connortsui20 connortsui20 commented Oct 29, 2026 •

Copy link
Copy Markdown
Member

Summary

take and mask can make an extension array nullable, while min_max builds non-null result dtypes. These operations need to change nullability without failing. Previously, ExtDType::with_nullability called the plugin validator again and panicked if it returned an error.

An extension type must accept either top-level nullability, so an already valid dtype can be reused with that flag changed. with_nullability now relies on this contract instead of validating again.

Changes

Keeps metadata and storage types intact when changing nullability. Also fixes erased dtype Debug output, which wrote metadata before the struct and displayed metadata: Ok(()) in its place.

Regression tests cover both nullabilities, validation call counts, and compact and pretty Debug output. Checks for the style cleanup are left to CI.

API Changes

Documents that ExtVTable::validate_dtype must be independent of the storage dtype's top-level nullability. Validators can still constrain nullability inside nested storage types.

@connortsui20 connortsui20 added the changelog/break A breaking API change label Oct 29, 2026 — with ChatGPT Codex Connector
@codspeed

codspeed Bot commented Oct 29, 2026 •

Copy link
Copy Markdown

Merging this PR will degrade performance by 13.98%

2 warnings

⚠️ Walltime results may be unreliable

Some benchmarks used the Walltime instrument outside CodSpeed Macro Runners, which can make the results inconsistent.

Learn more about Macro Runners

See affected benchmarks

⚠️ 1 benchmark is dominated by system calls

System calls cannot be simulated consistently and are left out of the measure. The reported value understates the real cost. Switch to the Walltime instrument to measure them.

Learn more about system calls

See affected benchmarks

❌ 6 regressed benchmarks
✅ 2312 untouched benchmarks

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

Mode Benchmark BASE HEAD Efficiency
❌ CPU Simulation bench_compare_varbin[(50000, 2)] 133.3 µs 161.9 µs -17.66%
❌ CPU Simulation bench_compare_varbin[(50000, 64)] 135.3 µs 163.9 µs -17.48%
❌ CPU Simulation take_filter_primitive_small_uncached_random_mask_random_indices[4096, 10] 21.7 µs 24.7 µs -12.29%
❌ CPU Simulation bench_compare_sliced_dict_varbinview[(1000, 10000)] 78.1 µs 89 µs -12.25%
❌ CPU Simulation bench_compare_sliced_dict_varbinview[(7500, 10000)] 199.8 µs 227.6 µs -12.19%
❌ CPU Simulation bench_compare_sliced_dict_varbinview[(10000, 10000)] 206.1 µs 233.7 µs -11.79%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.


Comparing ct/ext-types/dtype-invariants (a5780e8) with develop (ea94807)

Open in CodSpeed

@connortsui20
connortsui20 marked this pull request as draft October 30, 2026 00:13
@connortsui20
connortsui20 force-pushed the ct/ext-types/dtype-invariants branch 2 times, most recently from 963b7ec to 35c68ec Compare October 30, 2026 13:46
@connortsui20

Copy link
Copy Markdown
Member Author

So this is definitely wrong, and it seems like we need to do a bit more design work around storage dtypes and nullability

@connortsui20
connortsui20 deleted the ct/ext-types/dtype-invariants branch October 30, 2026 14:02
An extension type cannot restrict whether its values can be null, so
`ExtVTable::validate_dtype` must not depend on the top-level nullability
of the storage dtype. `ExtDType::with_nullability` now relies on that
contract and rebuilds the dtype without validating again, so nullability
changes in `take`, `mask` and `min_max` cannot panic.

Also fixes `Debug for ExtDTypeRef`, which printed the metadata before the
struct and then `metadata: Ok(())`.

Signed-off-by: Connor Tsui <[email protected]>
@connortsui20
connortsui20 restored the ct/ext-types/dtype-invariants branch October 30, 2026 19:33
@connortsui20 connortsui20 reopened this Oct 30, 2026
@connortsui20 connortsui20 changed the title Validate extension dtype nullability and fix debug output Change extension dtype nullability without validating again Oct 30, 2026
@connortsui20
connortsui20 force-pushed the ct/ext-types/dtype-invariants branch from 35c68ec to f2c669e Compare October 30, 2026 19:34
@connortsui20
connortsui20 marked this pull request as ready for review October 30, 2026 21:10
@connortsui20
connortsui20 enabled auto-merge (squash) November 2, 2026 13:50
@connortsui20
connortsui20 merged commit b9b02f6 into develop Nov 2, 2026
72 of 73 checks passed
@connortsui20
connortsui20 deleted the ct/ext-types/dtype-invariants branch November 2, 2026 14:03
@connortsui20 connortsui20 mentioned this pull request Nov 2, 2026
9 tasks done
connortsui20 added a commit that referenced this pull request Nov 2, 2026
U2, U3, U4, U6, U7 and U8 merged on 2026-11-02 in #11012, #11014 and
#11016, and the DataFusion literal fix #11067 merged right after U2. So
order constraint 1 holds, and phase 1 starts from develop. The graph
shows these nodes as merged, and parts 2 and 4 name the PR that fixed
each finding.

#10953 now keeps i32 days and widens only the days part to i64 when a
value does not fit. It has no review, and it conflicts with the
DateTimeParts compare kernel that U2 changed. #11056 still waits on its
request for changes. #10661 replaces the closed #10482 for file sort
statistics.

In the type roadmap, only the N1 sentence changes.

Signed-off-by: Connor Tsui <[email protected]>
@connortsui20 connortsui20 mentioned this pull request Nov 2, 2026
12 of 49 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

changelog/break A breaking API change

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants