morningman opened a new pull request, #68935:
URL: https://github.com/apache/doris/pull/68935
### What problem does this PR solve?
Issue Number: None
Related PR: #68919, #67627, #68320
Problem Summary:
**In short.** On master, an INSERT that writes a UUID value into the VARIANT
column of a connector table, such as a Paimon `VARIANT` column, fails in
analysis with `can not cast from origin type UUID to target type=variant<...>`,
and so does an `ARRAY<UUID>` value. This PR lets the analyzer accept both. It
is not a branch-4.x port (branch-4.x has no UUID type); the gap came up in the
review of #68919, which ports branch-4.x write tests.
**Background.** A connector sink writes a VARIANT column through the Variant
V2 compute carrier: the sink casts the value to `ConnectorComputeVariantType`,
and `CheckCast` admits the source type only when
`VariantType.isSupportedComputeV2CastSource` accepts it. That predicate
(#68320) lists the scalar types the carrier can hold. The UUID type (#67627)
was merged the same day, and the BE carrier takes it
(`is_supported_variant_typed_identity` and the V2 CAST's
`is_supported_scalar_source` both include `TYPE_UUID`), but the FE predicate
does not: `UuidType` extends `PrimitiveType`, not `CharacterType`, so none of
the predicate's type families match it. An internal VARIANT column accepts the
same value through the strict cast whitelist.
**The problem, and what it cost.**
| Statement on a Paimon table `t (id INT, v VARIANT)` | master | with this
PR |
|---|---|---|
| `INSERT INTO t SELECT 1, CAST('6ba7b810-9dad-11d1-80b4-00c04fd430c8' AS
UUID)` | `can not cast from origin type UUID to target type=variant<...>`, with
`enable_strict_cast` on or off | written; reads back as
`6ba7b810-9dad-11d1-80b4-00c04fd430c8`, `variant_type` `uuid` |
| `INSERT INTO t SELECT 2, ARRAY(CAST('6ba7b811-9dad-11d1-80b4-00c04fd430c8'
AS UUID), NULL)` | `can not cast from origin type ARRAY<UUID> ...`, either mode
| written; reads back as `["6ba7b811-9dad-11d1-80b4-00c04fd430c8",null]` |
| `INSERT INTO t SELECT 3, CAST(CAST('6ba7b810-9dad-11d1-80b4-00c04fd430c8'
AS UUID) AS VARIANT)` | written | written (unchanged) |
So a UUID could reach a connector VARIANT column only through an explicit
`CAST(... AS VARIANT)`, which an INSERT into an internal table does not need.
**How this PR fixes it.** `isSupportedComputeV2CastSource` accepts
`UuidType`; the existing array recursion covers UUID array elements. The
predicate now admits the same scalar types as the BE carrier; TIME, VARBINARY
and 256-bit decimals stay rejected on both sides.
**Results.** On a local cluster with a file-system Paimon catalog, both
failing statements above succeed in both cast modes. The rows read back the
same through Doris and through the Paimon API
(`"6ba7b810-9dad-11d1-80b4-00c04fd430c8"` and
`["6ba7b811-9dad-11d1-80b4-00c04fd430c8",null]`), and match the row written
with the explicit cast.
### Release note
INSERT can write UUID and ARRAY<UUID> values into the VARIANT column of a
connector table, such as a Paimon table, without an explicit cast to VARIANT.
### Check List (For Author)
- Test: Regression test / Unit Test / Manual test
- FE UT: `CheckCastTest#testCastFromUuidToVariant` (UUID and
`ARRAY<UUID>` to the connector Variant type, as a scalar and as an array
target, in both cast modes). Removing the UUID check fails it.
- Regression: `external_table_p0/paimon/write/test_paimon_write_variant`
now writes UUID and `ARRAY<UUID>` rows in both cast modes. On master the suite
fails at that INSERT with the error above; with this PR the `.out` was
regenerated by the script and the suite passes, against the Paimon catalog of
the Iceberg docker environment.
- Manual: local file-system Paimon catalog, both cast modes, rows read
back through Doris and through the Paimon API.
- Behavior changed: Yes. UUID and `ARRAY<UUID>` sources are accepted for
connector VARIANT columns instead of being rejected in analysis.
- Does this need documentation: No
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
