Re: Change COPY ... ON_ERROR ignore to ON_ERROR ignore_row - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Change COPY ... ON_ERROR ignore to ON_ERROR ignore_row
Date
Msg-id 5e126dbb-9535-4de4-ad3b-187e475aa6b5@eisentraut.org
Whole thread Raw
In response to Re: Change COPY ... ON_ERROR ignore to ON_ERROR ignore_row  (jian he <jian.universality@gmail.com>)
Responses Re: Change COPY ... ON_ERROR ignore to ON_ERROR ignore_row
List 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.




pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: DOCS - pg_walsummary typo?
Next
From: Andrey Silitskiy
Date:
Subject: Re: Exit walsender before confirming remote flush in logical replication