CockroachDB accepts PostgreSQL session settings without applying them
The December beta improves ORM compatibility through catalogue queries and accepted session settings. Several settings are deliberately no-ops, so successful setup does not imply PostgreSQL semantics.
An application can fail to connect usefully to a database before executing any business query. A driver may issue session settings during initialization, and an ORM may inspect catalogue tables to discover the schema. CockroachDB's December 15 beta addresses both kinds of compatibility. Some newly accepted PostgreSQL settings deliberately do nothing, an important limit on what a successful setup statement proves.
The contemporary release notes name search_path, client_encoding, standard_conforming_strings, and client_min_messages. SET now recognizes those variables for PostgreSQL compatibility, but changing them has no effect. This can let software proceed past a connection-initialization sequence without implementing the underlying PostgreSQL behavior.
I see value in PostgreSQL wire compatibility because adopting a database becomes easier when familiar clients can connect. Its meaning still needs to be stated precisely. Accepting a setup command and implementing every semantic implication of that command are different levels of compatibility, and this beta documents the distinction directly.
A no-op can unblock a client
The implementation change, merged December 8, explicitly describes no-op support for those four variables as an ORM compatibility improvement. It also implements SHOW SERVER_VERSION, returning the PostgreSQL compatibility version already sent over pgwire. The change's description identifies that value as 9.5.0.
This makes the purpose of the reported version clear. It tells clients which PostgreSQL version CockroachDB most closely resembles. It does not identify CockroachDB as a PostgreSQL server or establish complete feature equivalence with PostgreSQL 9.5. A client using that number to choose SQL still needs the relevant behavior to exist.
The same reasoning applies to search_path. Recognizing its name can prevent a setup error, but this release explicitly says setting it has no effect. An application whose correctness depends on changing name resolution cannot infer that behavior from acceptance of the command. Compatibility at initialization is useful only within the documented semantics.
This is a practical engineering tradeoff. A client that sets a conventional default it never otherwise depends on can proceed. A client that relies on changing one of these variables still needs a different implementation or application adaptation. The release makes the first case easier without claiming to solve the second.
ORM compatibility includes catalogue query expressions
The beta also adds array-related facilities for standard introspection queries used by popular ORMs. array_agg supports integers and strings, the ANY, SOME, and ALL array operators become available, and GROUP BY can use array-typed columns. These are SQL expressions needed to process metadata as well as application data.
The notes qualify this support as applying to built-in tables only. They describe availability for user-generated tables as future work. That restriction is material because a query that works against the catalogue does not establish that the same array functionality is generally available across an application's schema.
A metadata query can combine joins and aggregation to reconstruct an object's definition. Supporting the catalogue relations alone may not be enough if the query also needs array aggregation or comparisons. This release therefore improves compatibility at the level of the expressions that introspection actually uses.
String arrays also receive a wire-format fix so their values are quoted correctly. That is another layer of the same interaction. The server must accept a query and compute a result, and its returned representation must then be understood by the driver. An ORM can encounter failure at any of those points even when its ordinary scalar queries succeed.
I prefer these enumerated changes to a broad promise that an ORM is supported in every configuration. They describe concrete behaviors that client integrations can depend on. The built-in-table limitation and the no-op settings also define where that dependence must stop.
Storage and cluster work continue below SQL
The beta updates RocksDB to 4.11.2. The release notes do not attach a general performance number to that update, so there is no basis here for claiming a particular improvement in application throughput. It is a named storage dependency change alongside the SQL compatibility work.
Raft snapshots are now applied one at a time. The release also improves detection of unresponsive nodes during asymmetric network partitions. These entries concern cluster operation below the PostgreSQL-compatible interface, reminding the reader that client compatibility sits over a separate distributed implementation.
The administrative interface gains lease-operation metrics and corrects aggregated rates. Those changes improve what an operator can inspect, while the compatibility changes improve what a client can ask. Neither transforms CockroachDB into the PostgreSQL implementation whose protocol it speaks.
For applications evaluating this beta, successful session initialization has a specific interpretation. It can mean that previously rejected conventional settings are now tolerated. The documented no-op behavior still governs those variables, and the added array facilities carry their stated built-in-table restriction. Those boundaries determine which existing client assumptions the release actually accommodates.