Move FOR PORTION OF Checks Out of Analysis
Core Problem
The FOR PORTION OF feature (a temporal/period-based SQL construct being added in PostgreSQL 19) has validation checks that are currently performed during query analysis (the parse analysis phase). This is architecturally incorrect for two reasons:
1. FDW Rejection Must Happen Later
Foreign Data Wrappers (FDWs) cannot support FOR PORTION OF operations, but checking for FDW involvement during analysis is insufficient because:
- The relation's status may change between analysis and execution — a table could become a foreign table (or vice versa) between when the query is parsed/planned and when it is executed. Checking at analysis time provides no guarantee the check is still valid at execution time.
- Child partitions must also be checked — In a partitioned table hierarchy, some partitions might be local while others are foreign tables. During analysis, the planner has not yet expanded partition trees, so it's impossible to verify that no child partition is an FDW. The check must be deferred to the planner/executor phase where the full partition tree is known.
2. Volatile Function Rejection Must Be Postponed
FOR PORTION OF likely needs to reject volatile functions in the temporal range expression (to prevent non-deterministic splitting of periods), but this check also cannot be done during analysis. The reasons likely include that expression simplification and function volatility categorization are more properly planner-phase concerns, and the expression tree may not be fully resolved at analysis time.
Proposed Solution
The fix is split into two patches:
-
Patch 1 (by jian he): Moves the FDW rejection check from analysis to the planner/executor phase, ensuring it catches both direct FDW relations and FDW child partitions. This patch originated from a prior thread and includes test revisions.
-
Patch 2 (by Paul Jungwirth): Postpones the volatile function check to a later phase as well, following the same architectural principle that runtime validation belongs in planning/execution, not analysis.
Architectural Significance
This is a classic example of a recurring PostgreSQL design principle: parse analysis should handle syntax and basic semantic validation, while runtime-dependent checks belong in the planner or executor. The partition expansion problem is particularly well-known — analysis operates on the "top-level" relation, while the planner is responsible for expanding inheritance/partition hierarchies and reasoning about individual children.
The fact that this is classified as an open item (not a commitfest entry) signals that it's considered a bug in PG19 development that must be resolved before release, rather than a new feature proposal.
Process Note
Álvaro Herrera corrected the process: since FOR PORTION OF is a new PG19 feature, issues introduced during its development are "open items" that block the release — they don't go through the normal commitfest workflow. This ensures the fix gets proper visibility and tracking on the PostgreSQL wiki's Open Items page.