Re: Change COPY ... ON_ERROR ignore to ON_ERROR ignore_row
Peter Eisentraut <peter@eisentraut.org>
From: Peter Eisentraut <peter@eisentraut.org>
To: jian he <jian.universality@gmail.com>
Cc: Matheus Alcantara <matheusssilv97@gmail.com>,
torikoshia <torikoshia@oss.nttdata.com>,
Masahiko Sawada <sawada.mshk@gmail.com>, vignesh C <vignesh21@gmail.com>,
Jim Jones <jim.jones@uni-muenster.de>, Kirill Reshke
<reshkekirill@gmail.com>, Fujii Masao <masao.fujii@oss.nttdata.com>,
"David G. Johnston" <david.g.johnston@gmail.com>,
Yugo NAGATA <nagata@sraoss.co.jp>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-03-03T06:38:18Z
Lists: pgsql-hackers
On 28.02.26 03:04, jian he wrote:
> On Wed, Feb 25, 2026 at 3:36 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>>
>> + if (cstate->opts.on_error == COPY_ON_ERROR_SET_NULL)
>> + {
>> + int attr_count = list_length(cstate->attnumlist);
>> +
>> + cstate->domain_with_constraint = palloc0_array(bool, attr_count);
>>
>> Maybe add a comment for this block to explain that you are collecting
>> information about domains for later.
>>
>
> Here is what I came up with:
>
> + /*
> + * When data type conversion fails and ON_ERROR is SET_NULL, we need
> + * ensure that input column allows NULL value, ExecConstraints will
> + * cover most of the cases, however it does not vertify domain
> + * constraints. Therefore, for constrained domains, NULL value check
> + * must be performed during the initial string-to-datum conversion
> + * (see CopyFromTextLikeOneRow).
> + */
>
>> + /*
>> + * If the column type is a constrained domain, an additional
>> + * InputFunctionCallSafe may be needed to raise error for
>> + * domain constraint violation.
>> + */
>>
>> Why "may be needed"? Is it sometimes not needed? Why, under what
>> circumstances?
>
> I changed the comments to:
>
> + /*
> + * For constrained domain types, we need an additional
> + * InputFunctionCallSafe to ensure that an error is thrown if
> + * the domain constraint rejects NULL.
> + */
>
>>
>> The subsequent error message writes "domain ... does not allow null
>> values", but AFAICT a domain input failure could also be due to a check
>> constraint failure? How would that be handled? The flow here is a bit
>> confusing.
>>
>
> create domain d3 as int check (value is not null);
> create table t(a d3);
> src4=# copy t1 from stdin (on_error set_null);
> Enter data to be copied followed by a newline.
> End with a backslash and a period on a line by itself, or an EOF signal.
>>> \N
>>> \.
> ERROR: domain d1 does not allow null values
> DETAIL: ON_ERROR SET_NULL cannot be applied because column "a"
> (domain d1) does not accept null values.
> CONTEXT: COPY t1, line 1, column a: null input
>
> It's more about whether all domain constraints allow a NULL value,
> In this context, the domain constraint is a CHECK constraint.
>
> ``InputFunctionCallSafe(&in_functions[m], NULL,``
> this check whether a NULL value is allowed for this domain.
> ExecConstraints does not handle domain constraints, so this is needed.
>
> The error message:
> ``errmsg("domain %s does not allow null values",``
> should be fine?
>
> All other suggestions have been incorporated into v24.
Thanks, committed.
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
file_fdw: Add regression test for file_fdw with ON_ERROR='set_null'
- d8879d34b9dd 19 (unreleased) landed
-
Add COPY (on_error set_null) option
- 2a525cc97e19 19 (unreleased) landed
-
Add REJECT_LIMIT option to the COPY command.
- 4ac2a9beceb1 18.0 cited
-
Add log_verbosity = 'silent' support to COPY command.
- e7834a1a251d 18.0 cited
-
Add new COPY option LOG_VERBOSITY.
- f5a227895e17 17.0 cited