Technical Analysis: Two Small errhint Cleanups in PG19 Code

Core Problem

This thread addresses two minor but important message quality issues in PostgreSQL 19's error hint (errhint) strings — the human-readable suggestions that accompany error messages to guide users toward resolution. While trivial in code complexity, these fixes reflect PostgreSQL's commitment to polished, consistent user-facing messaging, which is particularly important for error paths where users are already struggling.

Issue 1: Stray Word in pg_restore_extended_stats() errhint

In the import_pg_statistic() function (part of the extended statistics import/restore infrastructure), an errhint contains a grammatical error:

Value of element "%s" must be type a null or a string.

The word "type" is extraneous — likely a leftover from an earlier draft of the message (e.g., "must be of type null or string") that was partially rewritten but not fully cleaned up. The corrected message:

Value of element "%s" must be a null or a string.

This hint fires when importing serialized extended statistics and encountering an element value that is neither NULL nor a string, indicating corrupt or malformed input data.

Issue 2: Missing Period in Online Data Checksums errhint

In StartupXLOG(), when the startup process detects that a previous "enable data checksums" operation was interrupted (the online/non-stop checksums feature), it emits a hint:

Data checksum processing must be manually restarted for checksums to be enabled

This is missing the trailing period that PostgreSQL's message style guide mandates for hint messages. The PostgreSQL coding conventions (documented in src/backend/utils/errcodes.txt and the developer FAQ) specify that errhint messages should be complete sentences ending with periods, while primary errmsg strings should NOT end with periods. This distinction helps localization teams and maintains UI consistency.

Architectural Context

Extended Statistics Import (import_pg_statistic)

This code is part of the infrastructure for importing/exporting extended statistics — a feature that allows pg_dump/pg_restore to preserve multivariate statistics across dump/restore cycles. The function parses serialized statistic representations and validates element types during deserialization. This is relatively new infrastructure in the statistics subsystem.

Online Data Checksums (StartupXLOG)

The online data checksums feature allows enabling page-level checksums on a running cluster without requiring pg_checksums --enable in single-user mode or with the server stopped. The StartupXLOG() detection of an interrupted checksums-enable operation is a crash recovery safety check — if the process was interrupted, the cluster is in an inconsistent state where some pages have checksums and others don't, requiring manual intervention to restart the process.

Design Decisions and Style Conventions

These patches reinforce PostgreSQL's well-established message formatting conventions:

1. errhint messages are complete sentences ending with periods — they provide actionable guidance
2. errmsg messages do NOT end with periods — they state what went wrong
3. errdetail messages end with periods — they provide additional factual context

The project enforces these conventions strictly because PostgreSQL is translated into dozens of languages, and consistent formatting reduces translator burden and improves the quality of localized error output.

Regression Test Impact

Michael Paquier notes that the patch author forgot to update regression test expected outputs. Since one of these errhint strings is likely tested (the extended statistics import path has test coverage), the .out files in src/test/regress/expected/ need corresponding updates. Paquier indicates he'll handle this himself rather than requiring a v2 patch — standard practice for trivial fixups on small patches.

Assessment

This is a straightforward cleanup with no controversy. The patches are independently committable, touch unrelated subsystems, and improve message quality. The committer (Paquier) self-identifies as the author of one of the problematic messages and takes responsibility for committing both fixes with the necessary test output adjustments.