Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

repr: make WMR type coercion more like SQL #23633

Closed

Conversation

sploiselle
Copy link
Contributor

The code on main prevented you from using numeric values with different scales interchangeably, though SQL supports the operation.

@frankmcsherry Would you mind coming up with a minimal test case? I tried for a few minutes but couldn't get the angle of attack just right.

Motivation

This PR fixes a recognized bug. Slack

Checklist

  • This PR has adequate test coverage / QA involvement has been duly considered.
  • 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).
  • This PR includes the following user-facing behavior changes:
    • Improve type coercion in WITH MUTUALLY RECURSIVE queries. For example, you can now use NUMERIC values of arbitrary scales.

@sploiselle sploiselle requested review from a team December 3, 2023 14:09
@sploiselle sploiselle force-pushed the wmr-numeric-coercion branch from 33ee994 to 29ba87a Compare December 3, 2023 19:07
@sploiselle
Copy link
Contributor Author

Added a test case from Frank

bar(x NUMERIC) as (SELECT sum(a) FROM y)
SELECT * FROM bar
----
NULL
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we adjust this test case to test something more interesting than the base case? Ideally something that lets us "see" the coercion.

Copy link
Contributor

@benesch benesch left a comment

Choose a reason for hiding this comment

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

Thank you so much for this!

@sploiselle
Copy link
Contributor Author

Oh, this is PR's insufficient––the logic on main is sensible because it will not do any work to coerce from the return value to the declared type. For instance, you cannot enforce a limited scale on the return value. I'll come up with a more robust approach tomorrow.

@sploiselle sploiselle closed this Dec 4, 2023
@mgree
Copy link
Contributor

mgree commented Dec 4, 2023

For the next PR, we'll want a corresponding change in the optimizer's typechecking pass, too, in scalar_subtype_difference.

@sploiselle
Copy link
Contributor Author

@mgree Sorry I missed this when landing #23658––will take a look at this note now

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.

3 participants