On Tue, 19 Nov 2024 at 13:52, jian he <jian.universal...@gmail.com> wrote: > > On Sat, Nov 16, 2024 at 5:55 PM Kirill Reshke <reshkekir...@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
