Documentation Fix: pg_restore_extended_stats() Example Syntax Error

Core Problem

A trivial but potentially confusing typo was identified in the PostgreSQL documentation for the pg_restore_extended_stats() function. The example SQL call used a closing ); (end of function call) prematurely on the line providing the n_distinct argument, when it should have used a , (comma) to continue to the next named argument (dependencies). This would cause any user copying the example verbatim to receive a syntax error, undermining the utility of the documentation.

Technical Context

pg_restore_extended_stats() is a function used for restoring extended statistics objects (multivariate statistics) in PostgreSQL. Extended statistics cover:

• n_distinct: Multi-column distinct counts, stored as pg_ndistinct type
• dependencies: Functional dependency statistics, stored as pg_dependencies type
• exprs: Expression statistics

The function uses named parameter notation (e.g., 'relname', 'tab_name') which makes the call quite verbose. The documentation example demonstrates how to invoke this function with all parameters specified, making correct punctuation between arguments essential for readability and copy-paste correctness.

Resolution

The fix was straightforward — changing ); to , on the n_distinct line of the example. Michael Paquier committed the fix as 4111b91ab3d5.

Significance

While this is a minimal documentation-only fix, it matters because:

1. pg_restore_extended_stats() is a relatively new and specialized function that users are unlikely to know from memory
2. The named-parameter calling convention with type casts (e.g., ::pg_ndistinct) makes the syntax non-trivial to reconstruct without the example
3. Users testing or implementing extended statistics restore workflows (e.g., during logical replication or pg_dump/restore customization) would hit this immediately

Process Notes

This is a clean example of community-driven documentation quality improvement: a user testing the feature found the issue, reported it concisely with the exact location and fix indicated, and a committer acknowledged and resolved it promptly (within ~38 hours).