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

From jian he
Subject Re: Change COPY ... ON_ERROR ignore to ON_ERROR ignore_row
Date
Msg-id CACJufxG-bN_3-0qG2NsY2+07gMWwYkT1VNB1xfbxt9i-ZAyh9w@mail.gmail.com
Whole thread
In response to Re: Change COPY ... ON_ERROR ignore to ON_ERROR ignore_row  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: Change COPY ... ON_ERROR ignore to ON_ERROR ignore_row
List pgsql-hackers
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.


--
jian
https://www.enterprisedb.com/

Attachment

pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Partial Mode in Aggregate Functions
Next
From: Chao Li
Date:
Subject: Re: [PATCH] Add PQgetThreadLock() to expose the Kerberos/Curl mutex