Analysis: Documentation Punctuation Fix for UPDATE FOR PORTION OF
Core Problem
This is a minor documentation consistency issue in the newly added FOR PORTION OF clause documentation. The FOR PORTION OF feature is part of PostgreSQL's temporal table support (SQL:2011 temporal features), which allows operations on temporal ranges — specifically updating or deleting only the portion of a row's validity period that overlaps with a specified range.
The issue is purely textual: the description of the FOR PORTION OF syntax in ref/update.sgml was missing a comma before "where" in a parenthetical explanation, while the equivalent text in ref/delete.sgml correctly included it. The inconsistency likely arose because the two documentation files were edited separately (possibly by different authors or at different times during the temporal tables feature development), and a minor punctuation difference slipped through review.
Technical Context
The FOR PORTION OF clause is a significant SQL:2011 feature that enables temporal data manipulation:
UPDATE t FOR PORTION OF valid_period FROM '2025-01-01' TO '2025-06-01'
SET salary = 50000
WHERE emp_id = 1;
The documentation describes that the temporal range specification "must be in the form ( portion ), where portion is an expression..." — this is the sentence that had the inconsistency. While the fix is trivial, documentation consistency matters for a project of PostgreSQL's scale, particularly for newly introduced syntax where users are learning the feature for the first time.
Proposed Solution
A one-character patch: add a comma before "where" in doc/src/sgml/ref/update.sgml line 169 to match the equivalent text in doc/src/sgml/ref/delete.sgml line 166.
The contributor verified the fix by recompiling the documentation and confirming visual consistency between the rendered sql-update.html and sql-delete.html pages.
Significance
While trivially simple, this patch is representative of the PostgreSQL community's attention to documentation quality. The FOR PORTION OF feature is relatively new, and ensuring its documentation is polished and internally consistent helps adoption. The fast turnaround (patch applied within ~38 hours) reflects the low-risk nature of pure documentation fixes.