Bug Report: vtexplain fails on sharded UNION queries containing weight_string

[arthurschreiber]

Overview of the Issue

When vtexplain is used to generate the query plan for a UNION query against a sharded keyspace, vtexplain can fail with errors like:

coercion should not try to coerce this value to a text: INT32(4)

This is caused by the fact that the query planner might inject WEIGHT_STRING calls into the per-shard queries. Unfortunately vtexplain treats all function calls as returning integer values (even if WEIGHT_STRING actually returns a string).

Later, UNION queries are handled via the Distinct primitive that builds a probe table. The probe table uses the NullsafeHashcode function to generate hash codes for each column, falling back to WEIGHT_STRING values if a column has an unsupported collation. When NullsafeHashcode is called for the WEIGHT_STRING column, the original column type is passed in, which causes the coercion should not try to coerce this value to a text as the WEIGHT_STRING function is assumed to return an integer, but the original columns type (VARCHAR in this case) is passed into the NullsafeHashcode function.

Reproduction Steps

Use the SQL schema from go/vt/vtexplain/testdata/test-schema.sql, and the VSchema from go/vt/vtexplain/testdata/test-vschema.json to explain a query like:

(SELECT user.id, user.name FROM user WHERE user.id = 1) UNION (SELECT user.id, user.name FROM user WHERE user.id = 2)

Binary Version

v17 and earlier seem to be affected. v18 and later are not affected.

Operating System and Environment details

N/A

Log Fragments

N/A