Add support for EXECUTE IMMEDIATE statement

[aalbu]

Description

Fixes #17353

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

Additional context and related issues

Release notes

(x) Release notes are required, with the following suggested text:

# Section
* Add support for `EXECUTE IMMEDIATE`. ({issue}`17341`)

[findepi]

I posed some syntax comments in the issue: #17353

[electrum]

Looks good. The last two commits should be squashed.

@martint should also review

[kasiafi]

just skimmed

[martint]

No need for a separate variable for this. Inline it below.

[martint]

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");

[kasiafi]

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.

[kasiafi]

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.

[kasiafi]

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.

[kasiafi]

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.

[colebow]

I really don't like that we're merging new SQL syntax without docs the day before our normal release day...

@aalbu could you please try to follow-up with a docs PR? I think you can likely just add a blurb to execute.rst
cc @martint

[aalbu]

@aalbu could you please try to follow-up with a docs PR? I think you can likely just add a blurb to execute.rst cc @martint

Sorry, my bad. I'll write something up.