CTAS, materialized views, and dynamic tables: Corrected byte length for new string columns (Pending)¶

This behavior change corrects the byte length of string columns created by CREATE TABLE ... AS SELECT (CTAS), CREATE MATERIALIZED VIEW, and CREATE DYNAMIC TABLE statements when the output type isn’t specified explicitly. It applies only to columns created after the bundle is enabled. Existing columns aren’t modified, and queries aren’t expected to fail as a result of this change.

A string data type has two length properties: a logical length, which is the number of characters, and a byte length, which should always equal 4 x logical_length, capped at 134,217,728. Some existing columns don’t satisfy that relationship, and these statements copied the too-small byte length into each new column instead of recomputing it, giving those columns less capacity than their declared type implies.

The byte length isn’t part of the declared type, so it’s most visible in the data_type JSON returned by SHOW COLUMNS. The following examples assume that t1.c1 is an existing column whose data_type reports a length of 16,777,216 and a byteLength of 16,777,216.

Before the change:

A new string column inherited both the logical length and the byte length of the input expression:

Copy code

CREATE TABLE t2 AS SELECT c1 FROM t1;
SHOW COLUMNS IN TABLE t2;

Result:

Copy code

{
  "length": 16777216,
  "byteLength": 16777216
}

After the change:

A new string column inherits the logical length of the input expression, and the byte length is recomputed as 4 x logical_length, capped at 134,217,728. Using the same example:

Copy code

{
  "length": 16777216,
  "byteLength": 67108864
}

If you specify the output type explicitly, for example with CAST(c1 AS VARCHAR(100)), the behavior is unchanged.

A more targeted version of this fix was made for the UPPER and INITCAP functions in the 2026_04 behavior change bundle. This behavior change extends the fix to all CTAS, materialized view, and dynamic table expressions.

Ref: 2404