-
Notifications
You must be signed in to change notification settings - Fork 62
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
Merges main into v1 #1481
Conversation
Removes all logic regarding absent types in planner
Adds TODO Simplifies typing of index operator Updates comment
…missing Deprecates absent types and removes associated planner logic
Updates planning tests Removes exhaustive attribute from dynamic call
There was a problem hiding this 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)
partiql-planner/src/main/kotlin/org/partiql/planner/internal/typer/PlanTyper.kt
Outdated
Show resolved
Hide resolved
partiql-planner/src/test/kotlin/org/partiql/planner/PlannerErrorReportingTests.kt
Outdated
Show resolved
Hide resolved
partiql-planner/src/test/kotlin/org/partiql/planner/PlannerErrorReportingTests.kt
Show resolved
Hide resolved
partiql-planner/src/test/kotlin/org/partiql/planner/PlannerErrorReportingTests.kt
Outdated
Show resolved
Hide resolved
partiql-planner/src/test/kotlin/org/partiql/planner/PlannerErrorReportingTests.kt
Outdated
Show resolved
Hide resolved
@@ -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) ? |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
partiql-planner/src/test/kotlin/org/partiql/planner/internal/typer/PlanTyperTestsPorted.kt
Show resolved
Hide resolved
partiql-eval/src/test/kotlin/org/partiql/eval/internal/PartiQLEngineDefaultTest.kt
Show resolved
Hide resolved
// TODO remove in next major version release. | ||
rename("PartiQLParser.g4", "PartiQL.g4") |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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))) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this 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) ? |
There was a problem hiding this comment.
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).
partiql-eval/src/test/kotlin/org/partiql/eval/internal/PartiQLEngineDefaultTest.kt
Show resolved
Hide resolved
partiql-planner/src/test/kotlin/org/partiql/planner/PlannerErrorReportingTests.kt
Show resolved
Hide resolved
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 |
Description
main
intov1
.Other Information
This is unreleased
Do your changes comply with the Contributing Guidelines
and Code Style Guidelines? NO
License Information
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.