PostgreSQL 10 RC1 exposes client and server versions separately
PostgreSQL 10 RC1 adds psql variables for client and server versions. The release candidate also fixes feature interactions and requires an upgrade from earlier prereleases.
A database session has two relevant software versions before it runs its first application query. The server accepts SQL, while the client program interprets its own commands and scripts. PostgreSQL 10 RC1 makes that distinction easier to inspect by adding psql variables for the server and client versions. It is a small change in the September 21 announcement, but one with a concrete use in understanding mixed-version environments.
RC1 is the first release candidate for PostgreSQL 10. The project says a release candidate should be identical to the final release, while also noting known open issues and asking users to test. That is an expectation about readiness, not a statement that the final release has already happened. Further candidates remain possible until reported issues are resolved.
I value explicit version information because PostgreSQL's tools and database server are distinct parts of an installation. A script can depend on a client command even when its SQL works against an older server. Reporting both versions makes that dependency visible without pretending they are always upgraded together.
Server version follows the connection
The psql reference preserved at the RC1 tag defines SERVER_VERSION_NAME and SERVER_VERSION_NUM. They contain the connected server's version as a short string and a number. PostgreSQL sets them whenever the client connects to a database, including its initial connection.
That lifecycle matters when a script or interactive session changes connections. Server version information belongs to the current connection rather than permanently describing the client process. The documented values can be changed or unset, so they are useful session information, not an immutable security assertion.
The reference illustrates the numeric representation with an older release, 9.6.2, represented as 90602. Keeping a numeric form avoids requiring every consumer to parse a display-oriented version name for ordinary comparisons. A short string remains useful when a human needs to read the version in output.
The distinction between numeric and display representations also prevents a script from assuming that every version description is a simple sequence of dot-separated integers. A prerelease has a name as well as an internal version representation. The variables provide those forms directly instead of requiring a script to extract them from a longer message.
Client version belongs to the program
VERSION, VERSION_NAME, and VERSION_NUM describe psql itself. They are initialized when the program starts and provide a verbose string, a short string, and a number respectively. Like the server variables, the client variables can be changed or unset.
With this RC1 client connected, an interactive inspection can print both short names:
\echo :VERSION_NAME
\echo :SERVER_VERSION_NAME
The first line identifies the client whose metacommands the session is using. The second identifies the connected server. They answer different compatibility questions even when an administrator normally installs both from the same package set.
A client-side command must be understood by the running client. A server-side SQL construct must be understood by the connected server. Knowing the server's version alone cannot establish whether the client supports a particular scripting facility. Conversely, starting a new client does not add SQL syntax to an older server.
I consider this useful operational metadata because it gives a precise vocabulary to a common ambiguity in problem reports. Saying that a session uses PostgreSQL 10 can otherwise leave unclear whether that statement describes the server, the client tools, or both. The added variables let output state the distinction directly.
Release-candidate fixes still concern integration
The announcement lists fixes for partitioning, logical replication, and transition tables. It also corrects a query that could become uninterruptible. The short list does not describe every underlying defect, so it should not be read as a detailed mechanism for those fixes. It does identify the areas where testing of beta 4 found problems.
These corrections accompany applicable fixes from PostgreSQL 9.6 and earlier supported branches. RC1 therefore incorporates both issues specific to the developing major version and existing fixes that also apply to it. An application's behavior depends on those accumulated changes, not just on the latest headline features.
The project asks testers to consult the open-items page before filing reports. That instruction acknowledges that a release candidate can still contain known problems. Testing at this stage supplies evidence about the intended release's behavior, while the project's release process retains the option of another candidate.
Earlier prereleases require an upgrade
RC1 requires pg_dump and pg_restore, or pg_upgrade, when moving from beta 4 or earlier. That instruction is part of the candidate's compatibility contract. A successful installation of new binaries is not by itself the documented transition for an existing beta cluster.
This is relevant even for a disposable test environment because the state being tested has to match the supported upgrade path. Otherwise a failure can reflect an invalid prerelease transition instead of the application's behavior against RC1. Once connected through the intended setup, the separate client and server variables provide a direct record of which programs participated in the test.