FOR PORTION OF bugs

From: Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, Noah Misch <noah(at)leadboat(dot)com>
Subject: FOR PORTION OF bugs
Date: 2026-09-04 04:26:58
Message-ID: CA+renyV6QLOJYmLo3gbsg1Y+Crho8NqME1jJXgPbO_NgxfBaKQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Hackers,

Noah Misch found a number of new FOR PORTION OF bugs with some LLM
investigation. I've attached the original prompt and findings. Here is
a list with my own description of each:

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 for
temporal leftovers 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.

I've got some patches to fix all these (with D2+D12 grouped and
D3+D4+D10 grouped), but I'll make a separate thread for each fix. I
just wanted to have this message as something I could reference from
there.

[0] https://www.postgresql.org/message-id/flat/CAON2xHO5FJ1jC87cQhGg%2BKMG5QR7ZaifJwN24rPjMqCGYn-hzA%40mail.gmail.com
[1] https://www.postgresql.org/message-id/flat/CAN4CZFNSOA_LXWKC6sAOduWVsaxjzmFBNEHUQii89KUnMhBtcw%40mail.gmail.com

Yours,

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

Attachment Content-Type Size
PROVENANCE.md text/markdown 9.8 KB
FOR-PORTION-OF-DEFECTS.md text/markdown 30.2 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2026-09-04 04:28:10 Re: Support for 8-byte TOAST values, round two
Previous Message Tom Lane 2026-09-04 04:10:03 Re: [RFC PATCH] Cost-based delayed projection for ORDER BY ... LIMIT