Re: Small fix on COPY ON_ERROR document

On 2024-01-27 00:04, David G. Johnston wrote:
> On Fri, Jan 26, 2024 at 2:30 AM Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>
> wrote:
>
>> On Fri, 26 Jan 2024 00:00:57 -0700
>> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>>
>>> I will need to make this tweak and probably a couple others to my
>> own
>>> suggestions in 12 hours or so.
>>>
>
> And here is my v2.
>
> Notably I choose to introduce the verbiage "soft error" and then
> define in the ON_ERROR clause the specific soft error that matters
> here - "invalid input syntax".
>
> I also note the log message behavior when ignore mode is chosen. I
> haven't confirmed that it is accurate but that is readily tweaked if
> approved of.
>
> David J.

Thanks for refining the doc.

> + Specifies which how to behave when encountering a soft error.

To be consistent with other parts in the manual[1][2], should be “soft”
error?

> + An <replaceable class="parameter">error_action</replaceable>
> value of
> + <literal>stop</literal> means fail the command, while
> + <literal>ignore</literal> means discard the input row and
> continue with the next one.
> + The default is <literal>stop</literal>

Is "." required at the end of the line?

+ <para>
+ The only relevant soft error is "invalid input syntax", which
manifests when attempting
+ to create a column value from the text input.
+ </para>

I think it is not restricted to "invalid input syntax".
We can handle out of range error:

=# create table t1(i int);
CREATE TABLE

=# copy t1 from stdin with(ON_ERROR ignore);
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.
>> 111111111111111111111
>> \.
NOTICE: 1 row was skipped due to data type incompatibility
COPY 0

Also, I'm a little concerned that users might wonder what soft error is.

Certainly there are already references to "soft" errors in the manual,
but they seem to be for developer, such as creating new TYPE for
PostgreSQL.

It might be better to describe what soft error is like below:

> -- src/backend/utils/fmgr/README
> An error reported "softly" must be safe, in the sense that there is
> no question about our ability to continue normal processing of the
> transaction.

[1] https://www.postgresql.org/docs/devel/sql-createtype.html
[2] https://www.postgresql.org/docs/devel/functions-info.html

--
Regards,

--
Atsushi Torikoshi
NTT DATA Group Corporation