Re: expand on_error ignore error handling scope

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

In response to

Browse pgsql-hackers by date

  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)