-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Add support for EXECUTE IMMEDIATE statement #17341
Conversation
I posed some syntax comments in the issue: #17353 |
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.
Looks good. The last two commits should be squashed.
@martint should also review
core/trino-main/src/main/java/io/trino/execution/QueryPreparer.java
Outdated
Show resolved
Hide resolved
core/trino-main/src/main/java/io/trino/execution/QueryPreparer.java
Outdated
Show resolved
Hide resolved
...ng/trino-product-tests/src/main/java/io/trino/tests/product/jdbc/TestPreparedStatements.java
Outdated
Show resolved
Hide resolved
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.
just skimmed
core/trino-parser/src/main/java/io/trino/sql/tree/ExecuteImmediate.java
Outdated
Show resolved
Hide resolved
core/trino-main/src/main/java/io/trino/execution/QueryPreparer.java
Outdated
Show resolved
Hide resolved
6d80305
to
f1e0f26
Compare
catch (ParsingException e) { | ||
int embeddedStatementLine = executeImmediateStatement.getStatementLocation().getLineNumber(); | ||
int embeddedStatementColumn = executeImmediateStatement.getStatementLocation().getColumnNumber(); | ||
ParsingException exceptionWithUpdatedLocation = new ParsingException( |
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.
No need for a separate variable for this. Inline it below.
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.
Also, this won't work for a test such as this, as it only handles parsing errors:
assertTrinoExceptionThrownBy(() -> assertions.query("EXECUTE IMMEDIATE 'SELECT * FROM tiny.tpch.orders'"))
.hasMessageMatching("line 1:34: Catalog 'tiny' does not exist");
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.
If the SqlParser could take a "relative start position", it would solve both issues:
- parsing exceptions would have the correct location,
- the created AST would have the correct locations, so the Analyzer errors would be positioned correctly, too.
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.
Also, this won't work for a test such as this, as it only handles parsing errors:
BTW @martint we have the same problem with EXECUTE
:
trino> prepare test from select * from foo;
PREPARE
trino> execute test;
Query 20230510_184850_00010_fczhd failed: line 3:3: Schema must be specified when session schema is not set
It's even worse, as the line/column in error message refer to how the statement was formatter by the SqlFormatter, not to how it was originally written by the user.
Probably in this case we should skip the position altogether, or place it at the beginning of the EXECUTE
statement, or maybe include the executed statement in the message to gie context for the error.
core/trino-parser/src/main/java/io/trino/sql/parser/AstBuilder.java
Outdated
Show resolved
Hide resolved
core/trino-parser/src/main/java/io/trino/sql/tree/ExecuteImmediate.java
Outdated
Show resolved
Hide resolved
catch (ParsingException e) { | ||
int embeddedStatementLine = executeImmediateStatement.getStatementLocation().getLineNumber(); | ||
int embeddedStatementColumn = executeImmediateStatement.getStatementLocation().getColumnNumber(); | ||
ParsingException exceptionWithUpdatedLocation = new ParsingException( |
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.
If the SqlParser could take a "relative start position", it would solve both issues:
- parsing exceptions would have the correct location,
- the created AST would have the correct locations, so the Analyzer errors would be positioned correctly, too.
catch (ParsingException e) { | ||
int embeddedStatementLine = executeImmediateStatement.getStatementLocation().getLineNumber(); | ||
int embeddedStatementColumn = executeImmediateStatement.getStatementLocation().getColumnNumber(); | ||
ParsingException exceptionWithUpdatedLocation = new ParsingException( |
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.
Also, this won't work for a test such as this, as it only handles parsing errors:
BTW @martint we have the same problem with EXECUTE
:
trino> prepare test from select * from foo;
PREPARE
trino> execute test;
Query 20230510_184850_00010_fczhd failed: line 3:3: Schema must be specified when session schema is not set
It's even worse, as the line/column in error message refer to how the statement was formatter by the SqlFormatter, not to how it was originally written by the user.
Probably in this case we should skip the position altogether, or place it at the beginning of the EXECUTE
statement, or maybe include the executed statement in the message to gie context for the error.
core/trino-parser/src/main/java/io/trino/sql/parser/AstBuilder.java
Outdated
Show resolved
Hide resolved
core/trino-parser/src/main/java/io/trino/sql/parser/SqlParser.java
Outdated
Show resolved
Hide resolved
core/trino-main/src/main/java/io/trino/execution/QueryPreparer.java
Outdated
Show resolved
Hide resolved
core/trino-parser/src/main/java/io/trino/sql/parser/AstBuilder.java
Outdated
Show resolved
Hide resolved
core/trino-parser/src/main/java/io/trino/sql/parser/SqlParser.java
Outdated
Show resolved
Hide resolved
...ng/trino-product-tests/src/main/java/io/trino/tests/product/jdbc/TestPreparedStatements.java
Show resolved
Hide resolved
core/trino-parser/src/main/java/io/trino/sql/tree/ExecuteImmediate.java
Outdated
Show resolved
Hide resolved
core/trino-parser/src/main/java/io/trino/sql/tree/ExecuteImmediate.java
Outdated
Show resolved
Hide resolved
core/trino-parser/src/main/java/io/trino/sql/tree/ExecuteImmediate.java
Outdated
Show resolved
Hide resolved
core/trino-parser/src/main/java/io/trino/sql/tree/ExecuteImmediate.java
Outdated
Show resolved
Hide resolved
Syntax: EXECUTE IMMEDIATE 'SELECT * FROM t WHERE a = ? and b = ?' USING 'foo', 42 The semantics are the same as: PREPARE stmt1 FROM SELECT * FROM t WHERE a = ? and b = ? EXECUTE stmt1 USING 'foo', 42 DEALLOCATE PREPARE stmt1
Description
Fixes #17353
Syntax:
The semantics are the same as:
Additional context and related issues
Release notes
(x) Release notes are required, with the following suggested text: