BUG #19630: FOR PORTION OF crashes with XX000 when target range is NULL
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
This thread has been committed, so CI has stopped here. Anything below is the last result it produced.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253482psql -h localhost -U postgresBuilt from patchset v2 (message #2), August 21, 2026 at 11:27 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253482_2 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253482_2 && git checkout t253482_2Patchset v2 (message #2) is on t253482_2
The following bug has been logged on the website:
Bug reference: 19630
Logged by: Zheng Hacker
Email address: hackerzheng666@gmail.com
PostgreSQL version: 19beta3
Operating system: Linux x86_64
Description:
PostgreSQL version: 20devel (commit bdbf662, 2026-08-19)
OS: Linux x86_64
When a DELETE/UPDATE ... FOR PORTION OF receives a NULL range
target, it hits elog(ERROR) without errcode() in nodeModifyTable.c,
producing SQLSTATE XX000 instead of a proper error.
Reproducer:
CREATE TABLE t (
id int4range NOT NULL,
valid_at daterange NOT NULL,
name text NOT NULL,
CONSTRAINT t_pk PRIMARY KEY (id, valid_at WITHOUT OVERLAPS)
);
INSERT INTO t (id, valid_at, name)
VALUES ('[1,2)', '[2018-01-02,2020-01-01)', 'one');
DELETE FROM t FOR PORTION OF valid_at (NULL) WHERE id = '[1,2)';
-- ERROR: XX000: FOR PORTION OF target was null
-- LOCATION: ExecInitModifyTable, nodeModifyTable.c:5647
Expected: a proper SQLSTATE (e.g. 22004 null_value_not_allowed).
Found by automated SQL fuzzing.
Credit: Zheng Wang, Yanjie Zhao, Yiyang Liu
Thank you for the bug report!
The attached patch fixes the issue and improves the error message to
match other similar messages.