| From: | jian he <jian(dot)universality(at)gmail(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
| Cc: | Matheus Alcantara <matheusssilv97(at)gmail(dot)com>, torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Change COPY ... ON_ERROR ignore to ON_ERROR ignore_row |
| Date: | 2026-02-28 02:04:53 |
| Message-ID: | CACJufxG-bN_3-0qG2NsY2+07gMWwYkT1VNB1xfbxt9i-ZAyh9w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Feb 25, 2026 at 3:36 PM Peter Eisentraut <peter(at)eisentraut(dot)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.
| Attachment | Content-Type | Size |
|---|---|---|
| v24-0001-COPY-on_error-set_null.patch | text/x-patch | 23.6 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-02-28 03:12:24 | Re: [PATCH] Add PQgetThreadLock() to expose the Kerberos/Curl mutex |
| Previous Message | David G. Johnston | 2026-02-28 01:57:43 | Re: Partial Mode in Aggregate Functions |