On Tue, 19 Nov 2024 at 13:52, jian he <jian.universality@gmail.com> wrote:
>
> On Sat, Nov 16, 2024 at 5:55 PM Kirill Reshke <reshkekirill@gmail.com> wrote:
> >
> > I am attaching my v8 for reference.
> >
>
> in your v8.
>
> <varlistentry>
> <term><literal>REJECT_LIMIT</literal></term>
> <listitem>
> <para>
> Specifies the maximum number of errors tolerated while converting a
> column's input value to its data type, when <literal>ON_ERROR</literal> is
> set to <literal>ignore</literal>.
> If the input contains more erroneous rows than the specified
> value, the <command>COPY</command>
> command fails, even with <literal>ON_ERROR</literal> set to
> <literal>ignore</literal>.
> </para>
> </listitem>
> </varlistentry>
>
> then above description not meet with following example, (i think)
>
> create table t(a int not null);
> COPY t FROM STDIN WITH (on_error set_to_null, reject_limit 2);
> 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.
> >> a
> >> \.
> ERROR: null value in column "a" of relation "t" violates not-null constraint
> DETAIL: Failing row contains (null).
> CONTEXT: COPY t, line 1, column a: "a"
>
> Overall, I think
> making the domain not-null align with column level not-null would be a
> good thing.
>
>
> <para>
> Specifies how to behave when encountering an error converting a column's
> input value into its data type.
> An <replaceable class="parameter">error_action</replaceable> value of
> <literal>stop</literal> means fail the command,
> <literal>ignore</literal> means discard the input row and
> continue with the next one, and
> <literal>set_to_null</literal> means replace columns containing
> erroneous input values with <literal>null</literal> and move to the
> next row.
>
> "and move to the next row" is wrong?
> I think it should be " and move to the next field".
Hi! There is not too much time left in this CF, so I moved to the next one.
If you are going to work on this patch, I'm waiting on your feedback
or a v9 patch that answers the issues brought up in this discussion.
--
Best regards,
Kirill Reshke
