BUG #19844: COPY ON_ERROR set_null error context names the wrong column

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.