PostgreSQL 12 RC1 settles comparison behavior before release

String equality is not always byte equality. PostgreSQL 12's nondeterministic collations make that distinction explicit, and the first release candidate still contains repairs around the new behavior. The final testing stage therefore concerns query meaning as well as whether the server starts and accepts connections.

The September 26 announcement says RC1 should be identical to the initial PostgreSQL 12 release, while allowing for further fixes. General availability is planned for October 3 if no issue requires another candidate or a delay. That is a schedule stated today, not an assurance that testing can no longer change the result.

I value predictable database behavior, particularly when a schema expresses assumptions about text. The collation changes are interesting because they let a database represent a broader notion of equality. They also require the implementation to stop relying on assumptions that were valid when equal strings necessarily had identical bytes.

What nondeterministic means

The collation documentation in the RC1 source defines deterministic comparison as considering strings equal only when their byte sequences match. Nondeterministic comparison can consider different byte sequences equal. Case-insensitive and accent-insensitive comparison are examples, as are strings in different Unicode normalization forms.

The collation provider supplies the comparison behavior. PostgreSQL's deterministic flag controls whether it breaks a comparison tie using a bytewise comparison. Disabling that tiebreaker allows the provider's idea of equality to remain the database's result.

This is more specific than selecting a language-specific sort order. A collation can arrange strings according to linguistic rules and still distinguish bytewise differences when the provider otherwise treats them as equivalent. The new flag controls that final distinction.

The RC1 documentation gives the following creation form for a nondeterministic ICU collation.

CREATE COLLATION ndcoll (
    provider = icu,
    locale = 'und',
    deterministic = false
);

The documented example permits comparison of strings in different normal forms. More specialized ICU locale settings express other comparison choices. The important point is that setting the flag does not independently invent the desired case or accent rules. Those come from the provider and its configuration.

The same documentation states that standard and predefined collations remain deterministic, and user-defined collations are deterministic by default. Existing collations therefore do not all acquire broader equality merely because the server is upgraded. Nondeterministic behavior is a deliberate schema choice.

Comparison choices have implementation limits

The RC1 manual records a performance penalty for nondeterministic collations and says some operations, including pattern matching, are unavailable. This is a meaningful limit for applications that expect equality and text-pattern operations to be interchangeable.

A case-insensitive equality requirement does not automatically establish the desired semantics of every string operation. A database can support one comparison model while rejecting another operation whose implementation requires different assumptions. That is why the restrictions belong beside the creation syntax when evaluating the feature.

RC1 fixes handling of nondeterministic collations with pattern_ops operator classes. The announcement does not describe that repair as general support for pattern matching under these collations. The documented pattern-matching restriction remains separate from correcting how an operator class interacts with the collation setting.

The candidate also adds leakproof markings to certain string functions to improve support for nondeterministic collations. The announcement says this can improve some query plans. It gives no universal performance claim, and the collation documentation still describes a cost for the broader comparison semantics.

My preference is to make text equality an explicit database decision when it affects correctness. The new setting is useful for that purpose. Its restrictions also make clear why a schema change involving collation is more substantial than changing a display convention.

Beta installations need an upgrade operation

RC1 is not a drop-in binary replacement for earlier PostgreSQL 12 betas. The announcement explicitly requires an upgrade strategy like that used between major versions, naming pg_upgrade and dump and restore. That requirement applies to Beta 4 and earlier PostgreSQL 12 installations.

This matters to the purpose of a release-candidate environment. Reusing a beta data directory without the specified upgrade would not reproduce the supported path into RC1. An application test result is more useful when the database being exercised has been brought forward using the procedure the project requires.

The distinction is easy to miss because all the versions carry the same major-version number. Development releases can still change compatibility assumptions before the initial stable release. The candidate's upgrade instructions are therefore more authoritative than an expectation based on ordinary maintenance releases.

The announcement also removes ECPG DECLARE STATEMENT functionality and reverts the ecpglib major-version change. These are additional signs that the candidate includes decisions about the delivered interface, beyond resolving execution crashes. Users of the embedded SQL library need the candidate's actual behavior rather than a beta's provisional interface.

The release notes pinned to RC1 describe a wider set of proposed PostgreSQL 12 changes, including overridable CTE inlining and SQL/JSON paths. At this stage, RC1 offers a concrete version for application compatibility work. The announcement's remaining qualification is narrow but real, since a discovered issue can still justify another candidate before general availability.