Skip to content

Conversation

@taniabogatsch
Copy link
Contributor

What happens

The below query prepares a SELECT statement that contains two equal parameters. Both are referenced by $1. When preparing this statement, we first create a BoundParameterMap entry for the parameter in to_years($1), with "1" as its identifier. This bound parameter entry has return_type = UNKNOWN. Its respective BoundParameterExpression also has return_type = UNKNOWN. Later, in AddCastToTypeInternal, we determine we know the return type of this BoundParameterExpression, which is INTEGER. We adjust the BoundParameterExpression and its corresponding entry in the BoundParameterMap.

Now, when we bind the second parameter, we find the corresponding BoundParameterMap entry because both have the same identifier. bound_expr->return_type = return_type sets the return type of this BoundParameterExpression to UNKNOWN, which would potentially get propagated to the bind result and cause rebinding by thrown a ParameterNotResolved exception. However, because it is wrapped in a cast, this does not happen.

Because we found a type for the first parameter occurrence, and the CAST swallowed the second parameter occurrence, we later assumed that we do not have to rebind this prepared statement during execution. This leads to a leaking BoundParameterExpression with an UNKNOWN return type, which throws INTERNAL Error: Invalid PhysicalType for GetTypeIdSize.

statement ok
PREPARE s1 AS SELECT to_years($1), CAST(list_value($1) AS BIGINT[]);

statement ok
EXECUTE s1(1);

Fix

My fix always determines if we previously found a type for a matching BoundParameterMap entry (same identifier). If so, we always rebind when executing the prepared statement. This avoids leaking UNKNOWN types into execution by not rebinding. If there is a better/alternative solution to fix this, I am also very open to suggestions!

@Mytherin Mytherin merged commit ab38b59 into duckdb:main Oct 10, 2023
@Mytherin
Copy link
Collaborator

Thanks! LGTM

@taniabogatsch taniabogatsch deleted the list-prepared-bug branch October 11, 2023 13:03
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.

2 participants