Re: FOR PORTION OF bugs

On Sat, Sep 5, 2026 at 8:31 PM Paul A Jungwirth
<pj(at)illuminatedcomputing(dot)com> wrote:
>
> > D1: A DO INSTEAD rule skips inserting leftovers. (Already reported by [0].)
> > D2: PREPARE requires casting parameters in FOR PORTION OF bounds (e.g. $1::date), but we should coerce these automatically.
> > D3: EXPLAIN (GENERIC_PLAN) fails with `no value found for parameter 1`
> > D4: EXPLAIN with `FOR PORTION OF (null)` raises an error about the null target.
> > D5: elog if the range column's default opclass is for a concrete range type, not anyrange.
> > D6: Under plain inheritance, statement-level insert triggers fire against the parent table, not the child.
> > D7: Error hint is misleading if a temporal leftover's BEFORE trigger modifies a row that is later changed by the top-level statement.
> > D8: A temporal leftover is not inserted if its BEFORE INSERT trigger returns null. (Already reported by [1].)
> > D9: FOR PORTION OF bound expressions are evaluated more than once. A function declared STABLE but not actually STABLE would get inconsistent results. Also reachable with current_setting() + set_config().
> > D10: EXPLAIN evaluates functions in the FOR PORTION OF bounds.
> > D11: A WITH CHECK OPTION failure blames the temporal leftover when it should blame the original update.
> > D12: pg_get_ruledef deparses a null bound as NULL::unknown not NULL::date.
> > D13: Docs should clarify that you need permission on the range column.
> > D14: Error message is misleading for a view referencing the range column twice.
>
> All of these have patches now and are in the Open Items list. Some of
> these shared a root cause, so there is a single patch fixing D2-D12
> (coercing parameters in FOR PORTION OF bounds) and another fixing
> D3-D4-D10 (evaluating bounds within EXPLAIN).

I was asked off-list not to add non-essential items to the Open Items
list. Several of these findings are cosmetic (improving error messages
or making minor documentation updates) or not a bug (STABLE functions
that aren't stable can give inconsistent results). So I will move
those to the appropriate category in that list. I just wanted to share
all the information I had and make sure others had a chance to give
feedback. We can always move things back if people think they need to
be part of v19.

Yours,

--
Paul ~{:-)
pj(at)illuminatedcomputing(dot)com