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

Validate literals in expression analyzer #10720

Conversation

findepi
Copy link
Member

@findepi findepi commented Jan 21, 2022

As a result, optimizer can safely assume a Literal to represent a
value of given type. Also, queries with invalid literal values should be
guaranteed to fail, regardless of expression pruning.

Fixes #10719
Fixes #10755

Copy link
Member

@kasiafi kasiafi left a comment

Choose a reason for hiding this comment

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

Please cover also:

  • GenericLiteral with type JSON,
  • IntervalLiteral

In fact, you could use LiteralInterpreter for the validation.

@findepi
Copy link
Member Author

findepi commented Jan 21, 2022

In fact, you could use LiteralInterpreter for the validation.

I thought about that, i chose not to, because i already have resolved coercion at hand, so LiteralInterpreter didn't buy me much.

@findepi findepi force-pushed the findepi/validate-literals-in-expression-analyzer-d1fe12 branch from 4ee442d to d3670d8 Compare January 21, 2022 11:13
@findepi
Copy link
Member Author

findepi commented Jan 21, 2022

In fact, you could use LiteralInterpreter for the validation.

switched over to LiteralInterpreter, as otherwise JSON verification would be cumbersome

Please cover also:

  • GenericLiteral with type JSON,
  • IntervalLiteral

added

// json
assertFails("SELECT JSON ''")
.hasErrorCode(INVALID_LITERAL);
// TODO https://github.com/trinodb/trino/issues/10724 these should fail
Copy link
Member Author

Choose a reason for hiding this comment

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

@findepi findepi force-pushed the findepi/validate-literals-in-expression-analyzer-d1fe12 branch from d3670d8 to bc3af3f Compare January 21, 2022 15:06
Comment on lines 195 to 196
// TODO (https://github.com/trinodb/trino/issues/10732) the expressions here may fail or not, depending whether they are wrapped
// should deterministically fail with NUMERIC_VALUE_OUT_OF_RANGE
Copy link
Member Author

Choose a reason for hiding this comment

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

@findepi findepi requested a review from kasiafi January 21, 2022 15:07
@findepi findepi force-pushed the findepi/validate-literals-in-expression-analyzer-d1fe12 branch from bc3af3f to bc0899b Compare January 21, 2022 20:31
@@ -5440,7 +5440,7 @@ public void testTry()
assertQuery("SELECT apply(5 + RANDOM(1), x -> x + TRY(1 / 0))", "SELECT NULL");

// test try with invalid JSON
assertQuery("SELECT JSON_FORMAT(TRY(JSON 'INVALID'))", "SELECT NULL");
assertQueryFails("SELECT JSON_FORMAT(TRY(JSON 'INVALID'))", "line 1:24: 'INVALID' is not a valid json literal");
Copy link
Member Author

@findepi findepi Jan 21, 2022

Choose a reason for hiding this comment

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

This is a behavioral change, but IMO justified.

#10755

@@ -5455,7 +5455,7 @@ public void testTry()
assertQuery("SELECT COALESCE(TRY(CAST(CONCAT('a', CAST(123 AS VARCHAR)) AS BIGINT)), 0)", "SELECT 0L");
assertQuery("SELECT 123 + TRY(ABS(-9223372036854775807 - 1))", "SELECT NULL");
assertQuery("SELECT JSON_FORMAT(TRY(JSON '[]')) || '123'", "SELECT '[]123'");
assertQuery("SELECT JSON_FORMAT(TRY(JSON 'INVALID')) || '123'", "SELECT NULL");
assertQueryFails("SELECT JSON_FORMAT(TRY(JSON 'INVALID')) || '123'", "line 1:24: 'INVALID' is not a valid json literal");
Copy link
Member Author

Choose a reason for hiding this comment

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

This is a behavioral change -- see above.

@findepi
Copy link
Member Author

findepi commented Jan 27, 2022

rebased to resolve conflict with #10737

@findepi findepi force-pushed the findepi/validate-literals-in-expression-analyzer-d1fe12 branch 2 times, most recently from 0a7d720 to 26dbcac Compare January 27, 2022 13:56
@findepi
Copy link
Member Author

findepi commented Jan 27, 2022

To be rebased after #10783 is merged.

@findepi findepi force-pushed the findepi/validate-literals-in-expression-analyzer-d1fe12 branch from 26dbcac to 4d65d6c Compare January 27, 2022 14:59
@findepi
Copy link
Member Author

findepi commented Jan 27, 2022

rebased after #10783 merged (no changes yet)

As a result, optimizer can safely assume a `Literal` to represent a
value of given type. Also, queries with invalid literal values should be
guaranteed to fail, regardless of expression pruning.
@findepi findepi force-pushed the findepi/validate-literals-in-expression-analyzer-d1fe12 branch from 4d65d6c to d4dc855 Compare January 27, 2022 15:07
@findepi findepi merged commit c8540c7 into trinodb:master Jan 27, 2022
@findepi findepi deleted the findepi/validate-literals-in-expression-analyzer-d1fe12 branch January 27, 2022 20:14
@github-actions github-actions bot added this to the 370 milestone Jan 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

Inconsistent handling of invalid literals within in try(...) Literals should be validated before optimizer
2 participants