CockroachDB 2.0.2 resolves PostgreSQL-style index names

An index name can be valid SQL syntax and still identify no object under a database's naming rules. CockroachDB and PostgreSQL organize index names differently, so administrative SQL generated by an existing tool can expose that difference. CockroachDB 2.0.2 expands the resolution of index names to handle more PostgreSQL-style qualifications.

The May 21 release notes identify improvements for statements such as DROP INDEX and ALTER INDEX RENAME. This is a useful compatibility change because migration tools generate those statements from their own model of the namespace. They may qualify an index even when an interactive user would choose CockroachDB's table-specific notation.

I appreciate the adoption benefit of the PostgreSQL protocol, but object naming is part of the compatibility work that follows it. A migration tool needs to identify the intended object consistently. Accepting the connection and supporting the command are insufficient if the database interprets the supplied name under different rules.

Indexes belong to different namespaces

Raphael Poss's patch in pull request 24817 explains the distinction. CockroachDB index names are relative to a table, commonly expressed as table@index. PostgreSQL index names live in a schema namespace. CockroachDB already searched tables for an index when the supplied name omitted its @ notation, but that search did not support qualified names properly.

The patch description gives TypeORM as a concrete caller issuing a schema-qualified index name. That makes the problem more specific than a general request for additional syntax. Existing software had a reason to generate a qualified name. The database's compatibility layer needed to resolve that form against its own organization of indexes.

The solution extends partial and complete qualification using the name-resolution rules applied to other objects. It does not change every index into an independent schema object internally. That distinction matters because a compatibility layer can translate an external naming convention while retaining its own storage and metadata organization.

Such translation needs to preserve ambiguity errors. If several tables have the same index name, a name without its table context may not identify one intended object. The resolver's documented behavior includes an error for ambiguity. Rejecting an ambiguous request is preferable to selecting a table based on an incidental search order.

Tests distinguish schemas from databases

The patch's SQL tests exercise unqualified names, schema-qualified names and database-qualified names retained for earlier CockroachDB compatibility. They also create a database named public. This deliberately awkward case tests whether public in a shorter name is being treated as a schema or as that database.

That is a useful test of meaning beyond parsing. A parser can recognize a dotted identifier without deciding what each component denotes. Resolution has to interpret those components in the current database and search path. The example forces the implementation to distinguish interpretations that a less carefully chosen name might conceal. The tests therefore describe which object a command should reach, including when a shorter spelling must fail.

Another test supplies an invalid search path and expects a specific error for the unqualified index. A sufficiently qualified name then succeeds. That demonstrates the purpose of qualification, to supply context that the ambient session cannot otherwise provide. It also gives users a more useful explanation when no schema is available for the search.

My preference is for naming failures to expose that missing context directly. A message saying only that an object does not exist can conceal a wrong database or schema selection. A more precise resolution error directs attention to the namespace in which the lookup occurred.

Administrative compatibility is operational behavior

These changes matter during schema maintenance, where generated SQL may execute under a connection configuration different from a developer's interactive shell. A statement that relied on a default database or search path can behave differently in that environment. Explicit qualification makes the intended context visible, provided the database supports the qualified form the tool emits.

The release also improves log identification by including the cluster ID in new log-file headers once it is known. It reports that ID in the initial log with a configuration tag. That is another small interface improvement with an operational purpose, helping identify which cluster produced a file before interpreting its contents.

A log line's meaning depends on its source just as an object name's meaning depends on its namespace. The two changes solve different problems, but both reduce missing context in routine administration. Neither requires a new application query feature to be useful.

For users of 2.0.2, the relevant result is broader compatibility for index-oriented administrative statements. Tools that emit qualified PostgreSQL-style names have more supported forms available. The resolver still needs enough context to identify one index, and its tests explicitly cover the cases where schema selection or ambiguity prevents that identification.