Skip to content

fix: default result parameter type

Denis Smirnov requested to merge tarantool_7283 into 2.10.0-picodata

Problem description.

When we prepare a statement with parameters in the result columns (for example box.prepare('select ?')) Tarantool has no information about the type of the output column and set it to default boolean. Then, on the execution phase, the type would be recalculated during the parameter binding.

Tarantool expects that there is no way for parameter to appear in the result tuple other than exactly be mentioned in the final projection. But it is incorrect - we can easily propagate parameter from the inner part of the join. For example

box.prepare([[select COLUMN_1 from t1 join (values (?)) as t2 on true]])

In this case column COLUMN_1 in the final projection is not a parameter, but a "reference" to it and its type depends on the parameter from the inner part of the join. But as Tarantool recalculates only binded parameters in the result projection, it doesn't change the default boolean metadata type of the COLUMN_1 and the query fails on comparison with the actual type of the tuple.

Solution.

As we don't want to patch Vdbe to make COLUMN_1 refer inner parameter it was decided to make a simple workaround: change the default column type from BOOLEAN to ANY for parameters. It fixes the comparison with the actual tuple type (we do not fail), but in some cases get ANY column in the results where we would like to have explicitly defined type. Also NULL parameters would also have ANY type, though Tarantool prefers to have BOOLEAN in this case.

Closes https://github.com/tarantool/tarantool/issues/7283

NO_DOC=bug fix

I also had to fix a flaky test test/box-luatest/gh_6634_different_log_on_tuple_new_and_free_test.lua. It checked that we print correctly in the logs the address of the replaced tuple during GC. Fo some reason the test was searching for the first string with tuple_delete in the log at expected it to be the one we are looking for. Fixed to make it search for exactly the deleted address we need, not the first one.

Edited by Denis Smirnov

Merge request reports