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

Merges main into v1 #1481

Merged
merged 15 commits into from
Jun 11, 2024
Merged

Merges main into v1 #1481

merged 15 commits into from
Jun 11, 2024

Conversation

johnedquinn
Copy link
Member

Description

  • Merges main into v1.
  • These changes notably contain the removal of NullType and MissingType. I'd mostly look at the final commit (cc3654a) to see what I needed to change.

Other Information

License Information

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Copy link
Member

@alancai98 alancai98 left a comment

Choose a reason for hiding this comment

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

Reviewed just the last commit fixing the tests cc3654a (#1481)

@@ -760,22 +760,19 @@ class PlanTyperTestsPorted {
ErrorTestCase(
name = "BITWISE_AND_MISSING_OPERAND",
query = "1 & MISSING",
expected = unionOf(INT4, INT8, INT),
expected = ANY, // TODO: Is this unionOf(INT4, INT8, INT) ?
Copy link
Member

Choose a reason for hiding this comment

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

Hmm thought it should also be the union(INT4, INT8, INT) #1463. May need to check this again?

Copy link
Member Author

Choose a reason for hiding this comment

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

Agreed -- however, I'd like to just get this in. Realistically, if we want to narrow down the type, this can be accomplished using the "unknown" type that PostgreSQL exposes.

Copy link
Member

Choose a reason for hiding this comment

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

Could consider capturing the future addition of an "unknown" type in a GH issue. Since this is just a merge, we can punt on the behavior on this (and similar tests).

Comment on lines +93 to +94
// TODO remove in next major version release.
rename("PartiQLParser.g4", "PartiQL.g4")
Copy link
Member

Choose a reason for hiding this comment

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

Note to self to remove the rename in the v1 branch.

Copy link
Member Author

Choose a reason for hiding this comment

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

ACK. I'm going to keep it since we know that we plan on merging this to main to perform a release before V1. This should be removed once all of our deprecation notices are eventually deleted.

Comment on lines +43 to +52
rex(StaticType.ANY, rexOpMissing(problem, causes))

fun missingRex(causes: Rex.Op, problem: Problem): Rex =
rex(StaticType.MISSING, rexOpMissing(problem, listOf(causes)))
rex(StaticType.ANY, rexOpMissing(problem, listOf(causes)))

fun errorRex(causes: List<Rex.Op>, problem: Problem): Rex =
rex(StaticType.MISSING, rexOpErr(problem, causes))
rex(StaticType.ANY, rexOpErr(problem, causes))

fun errorRex(trace: Rex.Op, problem: Problem): Rex =
rex(StaticType.MISSING, rexOpErr(problem, listOf(trace)))
rex(StaticType.ANY, rexOpErr(problem, listOf(trace)))
Copy link
Member

Choose a reason for hiding this comment

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

Out of curiosity, will these become UNKNOWN?

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmm. Good question. I'm unsure. unknown is used for literal values whose types need to be inferred based on their context (and original value).

Just thinking out loud here, but the goal of the planner is to produce a plan that can be "almost" directly executed. Given our gradual nature, the execution must execute the same way as a fully typed plan would have. Therefore, if unknown is treated in such a way that it may be handled in function resolution, then I think it would be appropriate.

Maybe that is appropriate in some scenarios. But I'm also thinking about functions that always receive the missing value as one of its inputs. I imagine that, currently, this probably collapses as a problem to always return missing -- though, it should be typed as the original function's type.

Copy link
Member

@alancai98 alancai98 left a comment

Choose a reason for hiding this comment

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

Merge and updated tests look good. Left a minor suggestion to track adding an unknown type since there are a few tests that will have a different result type.

@@ -760,22 +760,19 @@ class PlanTyperTestsPorted {
ErrorTestCase(
name = "BITWISE_AND_MISSING_OPERAND",
query = "1 & MISSING",
expected = unionOf(INT4, INT8, INT),
expected = ANY, // TODO: Is this unionOf(INT4, INT8, INT) ?
Copy link
Member

Choose a reason for hiding this comment

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

Could consider capturing the future addition of an "unknown" type in a GH issue. Since this is just a merge, we can punt on the behavior on this (and similar tests).

@johnedquinn
Copy link
Member Author

As this was pre-approved, and there are no changes between this revision and 145991e, I'm overriding and merging. The conformance test fix is actively being worked on by @alancai98 on the main branch and will be ported to v1 after.

@johnedquinn johnedquinn merged commit 46fea3b into partiql:v1 Jun 11, 2024
6 checks passed
@johnedquinn johnedquinn deleted the v1-merge-main branch June 11, 2024 20:58
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