Skip to content

expr: BinaryFunc to use variadic input types#35033

Merged
antiguru merged 3 commits intoMaterializeInc:mainfrom
antiguru:variadic_datum_types
Feb 17, 2026
Merged

expr: BinaryFunc to use variadic input types#35033
antiguru merged 3 commits intoMaterializeInc:mainfrom
antiguru:variadic_datum_types

Conversation

@antiguru
Copy link
Member

@antiguru antiguru commented Feb 16, 2026

Switch binary functions to a single variadic input type. Instead of defining two input GATs, we define a single one, which we fix to be a tuple of two elements. This is a step toward unifying all function types.

@github-actions
Copy link

Pre-merge checklist

  • The PR title is descriptive and will make sense in the git log.
  • This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
  • If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.
  • This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
  • If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
  • If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).

@antiguru antiguru force-pushed the variadic_datum_types branch 3 times, most recently from efde6e7 to 2f15555 Compare February 17, 2026 12:47
Support tuples as parameters to sql functions. Use the new API for binary
functions.

Signed-off-by: Moritz Hoffmann <mh@materialize.com>
Signed-off-by: Moritz Hoffmann <mh@materialize.com>
@antiguru antiguru force-pushed the variadic_datum_types branch from 2f15555 to 0233224 Compare February 17, 2026 13:17
@antiguru antiguru changed the title expr: Variadic datum types with GATs expr: BinaryFunc to use variadic input types Feb 17, 2026
@antiguru antiguru marked this pull request as ready for review February 17, 2026 13:43
@antiguru antiguru requested review from a team as code owners February 17, 2026 13:43
@antiguru antiguru requested review from ggevay and petrosagg February 17, 2026 13:43
Copy link
Contributor

@petrosagg petrosagg left a comment

Choose a reason for hiding this comment

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

Overall looks great!

let a = a.eval(datums, temp_storage)?;
let b = b.eval(datums, temp_storage)?;
let a = match T::Input1::try_from_result(Ok(a)) {
validate_arity::<T>(exprs.len());
Copy link
Contributor

Choose a reason for hiding this comment

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

This seems redundant with the assert_none!() afterwards. If the assert_none!() passes then it means that the call had exactly the right amount of datums in it, right?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, I'm undecided what's the best way to assert that we don't accidentally drop datums on the floor, and whether it's a reason to panic (I think yes) or produce an error (I think no).

We should call functions with correct parameters, instead of asserting
where it's too late.

Signed-off-by: Moritz Hoffmann <mh@materialize.com>
Copy link
Contributor

@petrosagg petrosagg left a comment

Choose a reason for hiding this comment

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

nice!

@antiguru antiguru merged commit 86b6eec into MaterializeInc:main Feb 17, 2026
134 checks passed
@antiguru antiguru deleted the variadic_datum_types branch February 17, 2026 16:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants