CockroachDB 1.1.4 aligns transaction settings with PostgreSQL

A database can accept a connection from an existing driver and still fail the driver's first inspection query. Compatibility includes the names and values returned by session settings, which client libraries may consume before application SQL runs. CockroachDB 1.1.4 addresses one such mismatch by aligning transaction-related session-variable names with PostgreSQL conventions.

The January 8 release notes rename the isolation, priority and status variables to transaction_isolation, transaction_priority and transaction_status. The first name follows PostgreSQL's setting, while the other two apply a consistent naming convention to CockroachDB's own settings. This is a small SQL-interface change with consequences for programs that inspect their connections.

I appreciate CockroachDB's use of the PostgreSQL wire protocol because it reduces adoption work. That benefit depends on details beyond accepting a socket connection. A driver or administrative client needs enough familiar behavior to initialize a session and interpret its state. These names are part of that behavior.

The spelling is an interface

The original change discussion in pull request 20301 explains that PostgreSQL reports isolation through transaction_isolation, with an underscore and a lowercase value. CockroachDB previously used a spaced name. The patch changes that representation and aligns the other transaction settings with it. Its motivation explicitly includes client behavior.

A human reading a status display can often recognize two labels as synonyms. A program looking up one specific identifier cannot make that inference unless someone implemented it. The spelling therefore carries a compatibility obligation even when the underlying isolation behavior is unchanged. Changing the name makes the existing concept accessible through the expected interface.

This distinction is useful when assessing a database that speaks another database's protocol. The protocol determines how messages travel. Session initialization determines which messages a client sends and which responses it expects. Compatibility at the first level does not establish compatibility at the second. Each observable detail can become part of an integration's assumptions.

The rename is also a reminder that compatibility changes can affect CockroachDB-specific scripts. A script written around the old variable name has a different dependency from a PostgreSQL client expecting the standard name. The change reduces one mismatch while changing an existing interface. Its release note needs to identify the exact names so both users can see the relevant dependency.

Local syntax checking depends on version knowledge

The same release changes how the command-line client behaves with a server of a different version. SQL-using commands warn when the server is older than the client. The SQL shell also limits automatic client-side syntax checking to matching client and server versions. These changes acknowledge that the client parser is not always authoritative about the server it reaches.

A client-side syntax error can be useful when both sides implement the same language. With different versions, the rejection may instead describe the client's limitations. A server could understand syntax the client does not, or a client could recognize syntax the server cannot execute. The version relationship determines how much confidence a local parser can provide.

Suppressing automatic local checking in that situation leaves the server responsible for interpreting the statement it receives. That does not make mixed-version operation fully compatible. It removes one particular reason for rejecting a request before the server has examined it. The warning still makes the version difference visible to the operator.

My preference is for a client to state what it knows about the server instead of silently applying its own assumptions. A version warning supplies relevant context for a later error. An automatic syntax check has a stronger effect because it can prevent the request from reaching the component that would execute it.

Compatibility reaches external storage too

Another change accepts HTTP 201 and 204 responses in the storage path used by import and related operations. The storage change discussion also mentions correctly closing unused response bodies. These changes concern the behavior of the HTTP integration, which has its own interface conventions outside SQL.

An integration needs to distinguish a response it can accept from a failure requiring recovery. If it recognizes only one successful response pattern, it can reject an operation that an external service considers successful. The right behavior depends on the operation and its documented responses. Merely receiving a response is insufficient evidence either way.

This gives the release a consistent practical theme without pretending that every fix changes the same subsystem. Transaction names affect SQL clients. Version checks affect the shell's interpretation of server capabilities. HTTP responses affect storage integration. Each change adjusts an assumption at the boundary between CockroachDB and another component.

For an application adopting this release, the relevant compatibility work is correspondingly specific. Session-inspection code needs the documented variable names. Operators using clients across versions need to understand the changed local validation behavior. Storage integrations gain acceptance of the additional documented response codes, so their successful operations are no longer rejected for those codes alone.