CockroachDB 23.1.14 resolves enum types inside imported arrays
Importing arrays of user-defined types requires type resolution inside each value. The January maintenance release supports that path while retaining a restriction on same-named types in different schemas.
A table can support an enum array while its bulk importer cannot reconstruct that array from text. CockroachDB 23.1.14, released on January 17, closes that gap for IMPORT INTO. The change supports columns containing arrays of user-defined types, including enums. It retains a restriction when a table uses multiple user-defined types with the same name in different schemas.
The backport implementation in pull request 116361 explains why the change required more than accepting an array delimiter. Values inside the array can contain casts naming an enum type. The importer needs enough semantic context to resolve those names to the actual database types before it can parse the values correctly.
I appreciate CockroachDB's PostgreSQL compatibility because it lowers the cost of adopting a distributed SQL system. This kind of change shows where compatibility extends beyond accepting a schema definition. An import path also has to interpret the values described by that schema, including types nested within another type.
Array parsing needs a type resolver
The implementation passes the existing semantic context into ParseDatumStringAs. Previously, callers created a fresh context. Reusing the available context allows parsing expressions that cast an enum member to a named type, such as the example 'Monday'::db.sc.enum_name in the pull request description. Resolving the cast is part of understanding the array element.
This distinction matters because the spelling of an enum member is not a complete type identity. The parser needs to know which enum the value belongs to. An array's element type carries that requirement into parsing of the whole array. Supporting an ordinary string array does not establish that a user-defined element type will work through the same path without resolution.
The change also implements importTypeResolver.ResolveType for the supported case. When the import job has the relevant set of types available, it can match a referenced type name against that set. The pull request explicitly describes this as an incomplete general implementation. That is the reason the release note states a boundary around which schemas the importer now accepts.
Same-named types remain ambiguous
The unresolved case is a table using two user-defined types with the same name under different schemas. Matching only the name cannot distinguish them safely. The implementation returns an error in that case, and the release notes preserve the limitation. General SQL name qualification and the importer's narrower resolver should not be treated as identical capabilities.
That gives a useful way to evaluate an affected schema. The question is not only whether it has an enum array. The set of types referenced by the table also matters, particularly whether their names collide across schemas. A table whose types have distinct names falls within a different resolver case from one relying on schema qualification to distinguish identical names.
The pull request also distinguishes importing into one table from broader import work where the available type set can differ. Its explanation mentions whole-dump import as an example of a different context. The January change should consequently be described as support for the named IMPORT INTO case, without turning it into a claim that every import format and every schema arrangement now has complete type resolution.
I prefer retaining that restriction in the description of the feature. A precise boundary is more useful than a broad compatibility claim that fails on a schema with legitimate type-name reuse. The release improves a real path while documenting the case where its resolution strategy still cannot identify a type safely.
Import remains a distinct database operation
The versioned IMPORT INTO documentation describes appending imported rows to an existing table. It takes that table offline during the job and brings it online again after successful completion. The new array support changes which typed values the importer can handle. It does not make the operation equivalent to ordinary online inserts from an application.
The documentation also describes insert-only behavior. Imported rows cannot conflict with existing primary or unique keys. This is relevant when choosing an import path for typed data because parsing compatibility and conflict behavior are independent requirements. Being able to decode an enum array does not imply that the importer can update an existing row containing one.
The statement lacks SELECT and WHERE clauses for choosing subsets of source rows. That keeps bulk loading distinct from a relational insert-select operation. A migration that needs filtering or updates has a separate requirement from the enum-array decoding addressed by this patch. The change removes one schema obstacle without redefining the statement's role.
January's maintenance release also fixes a prepared-statement failure involving an enum and a table that has undergone a schema change. That is another place where a named type interacts with database metadata, but it is a separate execution path. The import repair specifically supplies semantic context and a resolver while converting incoming values, so the supported enum-array schema can pass through the bulk-load operation.