On Sat, 7 Nov 2026 at 19:45, PG Bug reporting form <noreply(at)postgresql(dot)org>
wrote:
> The following bug has been logged on the website:
>
> Bug reference: 19844
> Logged by: Atish Prakash
> Email address: 125atishprak(at)gmail(dot)com
> PostgreSQL version: 19rc1
> Operating system: Linux x86_64
> Description:
>
> When ON_ERROR set_null replaces a value in the last column of a row, a
> later
> error for that row still reports that column in its CONTEXT line, even
> though
> the error has nothing to do with it:
>
> CREATE TABLE zp(a int, b int) PARTITION BY LIST (a);
> CREATE TABLE zp1 PARTITION OF zp FOR VALUES IN (1);
>
> COPY zp FROM STDIN (ON_ERROR set_null);
> 9 x
> \.
>
> Actual output:
>
> ERROR: no partition of relation "zp" found for row
> DETAIL: Partition key of the failing row contains (a) = (9).
> CONTEXT: COPY zp, line 1, column b: "x"
>
> Expected: the context does not blame column b, whose value was handled,
> since
> the failing partition key is column a:
>
> CONTEXT: COPY zp, line 1: "9 x"
>
> in NextCopyFrom(), the set_null path does "continue" before the
> statements that reset cstate->cur_attname and cur_attval. If the failing
> field
> is the last one, they stay set for the rest of the row's processing.
>
> A possible patch is attached (0001-fix-copy-set-null-error-context.patch),
> which
> removes that "continue" so the reset always runs. Regression tests pass
> with
> it
> on master; it adds no new test.
>
> Found with semantic differential tests . I reproduced and checked the
> result
> myself.
>
>
>