From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | jian he <jian(dot)universality(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: expand on_error ignore error handling scope |
Date: | 2025-04-30 01:03:12 |
Message-ID: | aBF20Al3fO3-MJPT@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 30, 2025 at 08:00:00AM +0800, jian he wrote:
> Currently, (on_error ignore) only handles data type incompatibility errors.
> However, we can extend its functionality to also handle errors caused by extra
> data (additional columns) or missing data (fewer columns), I think.
The original argument behind type incompatibility checks was that
incorrectly shaped multi-byte utf-8 character sequences could be
problematic, particularly if these are cut with a newline. It should
take care of most cases I've heard about (these should be arguments
about that around pg_bulkload, as well).
> on_error is only applicable to non-binary formats.
> In non-binary formats (such as text and CSV), COPY FROM cut income source row by
> row by newline. This means that row boundaries are clearly defined. If a
> line's contents cannot be successfully converted to the table's columns, an
> error is raised.
That depends. If the code can be made more verbose with more details
depending on the error path reached without blowing up the whole COPY,
knowing more about the incorrect state of a row without extending
ON_ERROR with a new mode seems useful to me.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Junwang Zhao | 2025-04-30 01:24:50 | Typo in multixact.c and jsonfuncs.c documentation |
Previous Message | Michael Paquier | 2025-04-30 00:57:46 | Re: Large expressions in indexes can't be stored (non-TOASTable) |