Skip to content

Adjust strict docs - #9033

Merged
connortsui20 merged 1 commit into
developfrom
ct/strict-docs-adjust
Jul 30, 2026
Merged

Adjust strict docs#9033
connortsui20 merged 1 commit into
developfrom
ct/strict-docs-adjust

Conversation

@connortsui20

Copy link
Copy Markdown
Member

Some of the semantics of strictness for the list scalar fns were unclear.

@connortsui20 connortsui20 added the changelog/docs A docs change label Jul 28, 2026
@connortsui20
connortsui20 enabled auto-merge (squash) July 28, 2026 14:30
Comment thread vortex-array/src/scalar_fn/vtable.rs Outdated
Comment thread vortex-array/src/scalar_fn/vtable.rs Outdated
@connortsui20
connortsui20 force-pushed the ct/strict-docs-adjust branch 3 times, most recently from 1578a48 to 4e778a7 Compare July 29, 2026 15:31
connortsui20 pushed a commit that referenced this pull request Jul 30, 2026
#9033 reaches the strictness-is-not-totality conclusion independently and lands
the documentation fix on develop, replacing the claimed validity equality with a
one-sided bound and deleting the dense-evaluation consequence outright.

Adopts that vocabulary here: is_total is now documented as the property that
upgrades valid(f(a..)) subset-of AND valid(aj) to an equality, which is what
makes the validity precomputable. The research doc records that #9033 supersedes
the doc half of the two issues filed from this branch, so what remains of them is
the API question and one regression test.

Also refreshes the doc for the ports since: geo moved from the columnar layer to
RowFn, list_sum joined the columnar layer, the constant-operand gap is closed, and
the remaining element-vocabulary gap is a nullable output element.

Signed-off-by: "Connor Sanders" <connor@spiraldb.com>
Comment thread vortex-array/src/scalar_fn/vtable.rs Outdated
@joseph-isaacs
joseph-isaacs disabled auto-merge July 30, 2026 15:48

@joseph-isaacs joseph-isaacs left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we all know what is important here, but I think strictness is too strong of a property and you actually want null_insensitivity.

It might be these are equiv properties and all cases I am not sure

@connortsui20

Copy link
Copy Markdown
Member Author

Given that strict is a more well defined thing (postgres) and we can't think of any examples where something is null insensitive but not strict I feel like it makes more sense to stick with this definition

@connortsui20

Copy link
Copy Markdown
Member Author

Closes #9091 which I filed by accident

Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
@connortsui20
connortsui20 force-pushed the ct/strict-docs-adjust branch from 4e778a7 to 55a1ce6 Compare July 30, 2026 16:43
@connortsui20
connortsui20 enabled auto-merge (squash) July 30, 2026 16:43
@connortsui20
connortsui20 merged commit bb4138d into develop Jul 30, 2026
73 checks passed
@connortsui20
connortsui20 deleted the ct/strict-docs-adjust branch July 30, 2026 16:53
connortsui20 pushed a commit that referenced this pull request Jul 30, 2026
Records why there are two authoring traits and not one or three, which trait
members are forced rather than chosen, the strictness-versus-totality finding and
how it lines up with #9033, the problems worth extracting onto develop separately,
and the known gaps the porting probes turned up.

Signed-off-by: "Connor Sanders" <connor@spiraldb.com>
connortsui20 pushed a commit that referenced this pull request Jul 30, 2026
Records why there are two authoring traits and not one or three, which trait
members are forced rather than chosen, the strictness-versus-totality finding and
how it lines up with #9033, the problems worth extracting onto develop separately,
and the known gaps the porting probes turned up.

Signed-off-by: "Connor Sanders" <connor@spiraldb.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

changelog/docs A docs change

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants