adriangb opened a new issue, #26917:
URL: https://github.com/apache/datafusion/issues/26917
### Describe the bug
A standalone `VALUES` list fails to plan when one row carries extension-type
metadata and another row is the bare storage type, even though the storage
types match:
```
Error during planning: Inconsistent metadata across values list at row 1
column 0. Was FieldMetadata { inner: {"ARROW:extension:name": "arrow.uuid"} }
but found FieldMetadata { inner: {} }
```
The same values are accepted by `INSERT INTO <uuid table> VALUES (...)`,
which plans `VALUES` against the target schema.
Found while reviewing https://github.com/apache/datafusion/pull/21714. The
check lives in `LogicalPlanBuilder` on `main` and reproduces there with the
test-only `UUID` type planner in `cast_extension_type_metadata.slt`, so it
predates that PR.
### To Reproduce
On #21714 (or in `cast_extension_type_metadata.slt` on `main`):
```sql
VALUES (CAST(X'00010203040506070809000102030506' AS UUID)),
(X'00010203040506070809000102030507');
-- Error during planning: Inconsistent metadata across values list at row 1
column 0 ...
```
### Expected behavior
This is arguably a usability gap rather than a correctness bug: an explicit
error is better than silently picking a type. But other systems unify these:
- Postgres: `VALUES ('...'::uuid), ('...')` → column typed `uuid`.
- DuckDB: same, column typed `UUID`.
Possible behavior: when the storage types match and the only difference is
that some rows have no metadata, use the extension type (as a cast), instead of
erroring.
--
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]
