On Tue, Apr 8, 2025 at 6:42 AM Masahiko Sawada wrote:
>
>
> BTW have you measured the overheads of calling InputFunctionCallSafe
> twice? If it's significant, we might want to find other ways to
> achieve it as it would not be good to incur overhead just for
> relatively rare cases.
>
Please chec
On Sat, Apr 5, 2025 at 1:31 AM jian he wrote:
>
> On Sat, Apr 5, 2025 at 5:33 AM Masahiko Sawada wrote:
> >
> > On Fri, Apr 4, 2025 at 4:55 AM jian he wrote:
> > >
> > > On Tue, Mar 25, 2025 at 2:31 PM vignesh C wrote:
> > > >
> > > > 2) Here in error we say column c1 violates not-null constrai
On Tue, 18 Mar 2025 at 09:26, jian he wrote:
>
> changed based on this.
>
> also minor documentation tweaks.
Few comments:
1) I felt this is wrong:
diff --git a/src/bin/psql/tab-complete.in.c b/src/bin/psql/tab-complete.in.c
index 9a4d993e2bc..7980513a9bd 100644
--- a/src/bin/psql/tab-complete.in
On Sat, Apr 5, 2025 at 5:33 AM Masahiko Sawada wrote:
>
> On Fri, Apr 4, 2025 at 4:55 AM jian he wrote:
> >
> > On Tue, Mar 25, 2025 at 2:31 PM vignesh C wrote:
> > >
> > > 2) Here in error we say column c1 violates not-null constraint and in
> > > the context we show column c2, should the conte
On Fri, Apr 4, 2025 at 4:55 AM jian he wrote:
>
> On Tue, Mar 25, 2025 at 2:31 PM vignesh C wrote:
> >
> > 2) Here in error we say column c1 violates not-null constraint and in
> > the context we show column c2, should the context also display c2
> > column:
> > postgres=# create table t3(c1 int
On Tue, Mar 25, 2025 at 2:31 PM vignesh C wrote:
>
> 2) Here in error we say column c1 violates not-null constraint and in
> the context we show column c2, should the context also display c2
> column:
> postgres=# create table t3(c1 int not null, c2 int, check (c1 > 10));
> CREATE TABLE
> postgres
On Mon, 24 Mar 2025 at 13:21, jian he wrote:
>
> I am not sure this is what we want.
> Anyway, I attached both two version
Few comments
1) I understood the problem, your first approach is ok for me.
2) Here in error we say column c1 violates not-null constraint and in
the context we show column
On Fri, Mar 21, 2025 at 2:34 PM vignesh C wrote:
>
> Few comments:
> 1) I felt this is wrong:
> diff --git a/src/bin/psql/tab-complete.in.c b/src/bin/psql/tab-complete.in.c
> index 9a4d993e2bc..7980513a9bd 100644
> --- a/src/bin/psql/tab-complete.in.c
> +++ b/src/bin/psql/tab-complete.in.c
> @@ -3
On Wed, Mar 12, 2025 at 4:26 PM Jim Jones wrote:
>
> >> 2) Inconsistent terminology. Invalid values in "on_error set_to_null"
> >> mode are names as "erroneous", but as "invalid" in "on_error stop" mode.
> >> I don't want to get into the semantics of erroneous or invalid, but
> >> sticking to one
On 12.03.25 09:00, jian he wrote:
>> 1) WARNING might be a better fit than NOTICE here.
>>
> but NOTICE, on_errror set_to_null is aligned with on_errror ignore.
>
>> I would still leave the extra messages from "log_verbosity verbose" as
>> NOTICE though. What do you think?
>>
>>
> When LOG_V
On Tue, Mar 11, 2025 at 6:31 PM Jim Jones wrote:
>
>
> I revisited this patch today. It applies and builds cleanly, and it
> works as expected.
>
> Some tests and minor comments:
>
hi. Jim Jones.
thanks for testsing it again!
>
>
> 1) WARNING might be a better fit than NOTICE here.
>
but
Hi Jian
On 07.03.25 04:48, jian he wrote:
> hi.
> rebase only.
I revisited this patch today. It applies and builds cleanly, and it
works as expected.
Some tests and minor comments:
1) WARNING might be a better fit than NOTICE here.
postgres=# \pset null NULL
Null display is "NULL".
post
hi.
rebase only.
From ce0ce6438094cad553e509db65b7fd27de2b9af6 Mon Sep 17 00:00:00 2001
From: jian he
Date: Fri, 7 Mar 2025 11:43:51 +0800
Subject: [PATCH v12 1/1] COPY (on_error set_to_null)
Extent "on_error action", introduce new option: on_error set_to_null.
Current grammar makes us unable to
On Tue, 14 Jan 2025 at 10:51, jian he wrote:
>
> the attached patch also did some doc enhancement, error message enhancement.
LGTM
--
Best regards,
Kirill Reshke
On Sat, Jan 11, 2025 at 5:54 PM Kirill Reshke wrote:
>
> On Fri, 10 Jan 2025 at 11:38, jian he wrote:
> > I think there are three remaining issues that may need more attention
> > 1.
> > Table 27.42. pg_stat_progress_copy View
> > (pg_stat_progress_copy)
> > column pg_stat_progress_copy.tuples_sk
On Fri, 10 Jan 2025 at 11:38, jian he wrote:
> I think there are three remaining issues that may need more attention
> 1.
> Table 27.42. pg_stat_progress_copy View
> (pg_stat_progress_copy)
> column pg_stat_progress_copy.tuples_skipped now the description is
> ""
> When the ON_ERROR option is set
On Wed, Jan 8, 2025 at 3:05 PM Kirill Reshke wrote:
>
> So, in this version you essentially removed support for REJECT_LIMIT +
> SET_TO_NULL feature? Looks like a promising change. It is more likely
> to see this committed.
> So, +1 on that too.
>
> However, v9 lacks tests for REJECT_LIMIT vs erro
Thank you for your update.
On Fri, 13 Dec 2024 at 08:15, jian he wrote:
>
> + /*
> + * Here we end processing of current COPY row.
> + * Update copy state counter for number of erroneous rows.
> + */
> + cstate->num_errors++;
> + cstate->escontext->error_occurred = true;
> +
> + /* Only print thi
+ /*
+ * Here we end processing of current COPY row.
+ * Update copy state counter for number of erroneous rows.
+ */
+ cstate->num_errors++;
+ cstate->escontext->error_occurred = true;
+
+ /* Only print this NOTICE message, if it will not be followed by ERROR */
+ if (cstate->opts.log_verbosity ==
On Tue, 19 Nov 2024 at 13:52, jian he wrote:
>
> On Sat, Nov 16, 2024 at 5:55 PM Kirill Reshke wrote:
> >
> > I am attaching my v8 for reference.
> >
>
> in your v8.
>
>
> REJECT_LIMIT
>
>
> Specifies the maximum number of errors tolerated while converting a
> colum
On Tue, 19 Nov 2024, 13:52 jian he, wrote:
>
> On Sat, Nov 16, 2024 at 5:55 PM Kirill Reshke wrote:
> >
> > I am attaching my v8 for reference.
> >
>
> in your v8.
>
>
> REJECT_LIMIT
>
>
> Specifies the maximum number of errors tolerated while converting a
> column'
On Sat, Nov 16, 2024 at 5:55 PM Kirill Reshke wrote:
>
> I am attaching my v8 for reference.
>
in your v8.
REJECT_LIMIT
Specifies the maximum number of errors tolerated while converting a
column's input value to its data type, when ON_ERROR is
set to ignore.
On Sat, Nov 9, 2024 at 8:55 PM Kirill Reshke wrote:
>
> > > But while I was trying to implement that, I realized that I don't
> > > understand v4 of this patch. My misunderstanding is about
> > > `t_on_error_null` tests. We are allowed to insert a NULL value for the
> > > first column of t_on_err
On Sat, 16 Nov 2024 at 13:27, jian he wrote:
>
> On Sat, Nov 9, 2024 at 8:55 PM Kirill Reshke wrote:
> >
>
> > > > But while I was trying to implement that, I realized that I don't
> > > > understand v4 of this patch. My misunderstanding is about
> > > > `t_on_error_null` tests. We are allowed to
On 2024-11-13 22:02, Yugo NAGATA wrote:
On Tue, 12 Nov 2024 17:38:25 +0900
torikoshia wrote:
On 2024-11-12 14:17, Yugo Nagata wrote:
> On Tue, 12 Nov 2024 14:03:50 +0900
> Yugo Nagata wrote:
>
>> On Tue, 12 Nov 2024 01:27:53 +0500
>> Kirill Reshke wrote:
>>
>> > On Mon, 11 Nov 2024 at 16:11,
On Tue, 12 Nov 2024 17:38:25 +0900
torikoshia wrote:
> On 2024-11-12 14:17, Yugo Nagata wrote:
> > On Tue, 12 Nov 2024 14:03:50 +0900
> > Yugo Nagata wrote:
> >
> >> On Tue, 12 Nov 2024 01:27:53 +0500
> >> Kirill Reshke wrote:
> >>
> >> > On Mon, 11 Nov 2024 at 16:11, torikoshia
> >> > wrot
On 2024-11-12 14:17, Yugo Nagata wrote:
On Tue, 12 Nov 2024 14:03:50 +0900
Yugo Nagata wrote:
On Tue, 12 Nov 2024 01:27:53 +0500
Kirill Reshke wrote:
> On Mon, 11 Nov 2024 at 16:11, torikoshia wrote:
> >
> > On 2024-11-09 21:55, Kirill Reshke wrote:
> >
> > Thanks for working on this!
>
> T
On Tue, 12 Nov 2024 01:27:53 +0500
Kirill Reshke wrote:
> On Mon, 11 Nov 2024 at 16:11, torikoshia wrote:
> >
> > On 2024-11-09 21:55, Kirill Reshke wrote:
> >
> > Thanks for working on this!
>
> Thanks for reviewing the v7 patch series!
>
> > > On Thu, 7 Nov 2024 at 23:00, Fujii Masao
> > >
On Tue, 12 Nov 2024 14:03:50 +0900
Yugo Nagata wrote:
> On Tue, 12 Nov 2024 01:27:53 +0500
> Kirill Reshke wrote:
>
> > On Mon, 11 Nov 2024 at 16:11, torikoshia wrote:
> > >
> > > On 2024-11-09 21:55, Kirill Reshke wrote:
> > >
> > > Thanks for working on this!
> >
> > Thanks for reviewing th
On Mon, 11 Nov 2024 at 16:11, torikoshia wrote:
>
> On 2024-11-09 21:55, Kirill Reshke wrote:
>
> Thanks for working on this!
Thanks for reviewing the v7 patch series!
> > On Thu, 7 Nov 2024 at 23:00, Fujii Masao
> > wrote:
> >>
> >>
> >>
> >> On 2024/10/26 6:03, Kirill Reshke wrote:
> >> > whe
On 2024-11-09 21:55, Kirill Reshke wrote:
Thanks for working on this!
On Thu, 7 Nov 2024 at 23:00, Fujii Masao
wrote:
On 2024/10/26 6:03, Kirill Reshke wrote:
> when the REJECT LIMIT is set to some non-zero number and the number of
> row NULL replacements exceeds the limit, is it OK to fai
On Thu, 7 Nov 2024 at 23:00, Fujii Masao wrote:
>
>
>
> On 2024/10/26 6:03, Kirill Reshke wrote:
> > when the REJECT LIMIT is set to some non-zero number and the number of
> > row NULL replacements exceeds the limit, is it OK to fail. Because
> > there WAS errors, and we should not tolerate more t
On 2024/10/26 6:03, Kirill Reshke wrote:
when the REJECT LIMIT is set to some non-zero number and the number of
row NULL replacements exceeds the limit, is it OK to fail. Because
there WAS errors, and we should not tolerate more than $limit errors .
I do find this behavior to be consistent.
On Mon, Oct 21, 2024 at 8:39 PM Fujii Masao wrote:
> On 2024/10/21 18:30, Kirill Reshke wrote:
> > v4 no longer applies. It now conflicts with
> > e7834a1a251d4a28245377f383ff20a657ba8262.
> > Also, there were review comments.
> >
> > So, I decided to rebase.
>
> Thanks for the patch! Here are my
Hi!
On Mon, 21 Oct 2024 at 17:39, Fujii Masao wrote:
>
>
>
> On 2024/10/21 18:30, Kirill Reshke wrote:
> > v4 no longer applies. It now conflicts with
> > e7834a1a251d4a28245377f383ff20a657ba8262.
> > Also, there were review comments.
> >
> > So, I decided to rebase.
>
> Thanks for the patch! Her
On 2024/10/21 18:30, Kirill Reshke wrote:
v4 no longer applies. It now conflicts with
e7834a1a251d4a28245377f383ff20a657ba8262.
Also, there were review comments.
So, I decided to rebase.
Thanks for the patch! Here are my review comments:
I noticed that on_error=set_to_null does not trigger
Hi!
On Thu, 12 Sept 2024 at 15:13, jian he wrote:
>
> On Mon, Sep 9, 2024 at 10:34 PM Jim Jones wrote:
> >
> >
> > Hi there
> >
> > On 26.08.24 02:00, jian he wrote:
> > > hi all.
> > > patch updated.
> > > simplified the code a lot.
> > >
> > > idea is same:
> > > COPY t_on_error_null FROM STDI
On 12.09.24 12:13, jian he wrote:
> please check the attached file.
v4 applies cleanly, it works as expected, and all tests pass.
postgres=# \pset null '(NULL)'
Null display is "(NULL)".
postgres=# CREATE TEMPORARY TABLE t2 (a int, b int);
CREATE TABLE
postgres=# COPY t2 (a,b) FROM STDIN WIT
On Mon, Sep 9, 2024 at 10:34 PM Jim Jones wrote:
>
>
> Hi there
>
> On 26.08.24 02:00, jian he wrote:
> > hi all.
> > patch updated.
> > simplified the code a lot.
> >
> > idea is same:
> > COPY t_on_error_null FROM STDIN WITH (on_error set_to_null);
> >
> > If the STDIN number of columns is the s
Hi there
On 26.08.24 02:00, jian he wrote:
> hi all.
> patch updated.
> simplified the code a lot.
>
> idea is same:
> COPY t_on_error_null FROM STDIN WITH (on_error set_to_null);
>
> If the STDIN number of columns is the same as the target table, then
> InputFunctionCallSafe
> call failure will
hi all.
patch updated.
simplified the code a lot.
idea is same:
COPY t_on_error_null FROM STDIN WITH (on_error set_to_null);
If the STDIN number of columns is the same as the target table, then
InputFunctionCallSafe
call failure will make that column values be null.
If the STDIN number of colum
On 16.02.24 21:31, David G. Johnston wrote:
> Yes. In particular not all columns in the table need be specified in
> the copy command so while the parsed input data is all nulls the
> record itself may not be.
Yeah, you have a point there.
I guess if users want to avoid it to happen they can r
On Fri, Feb 16, 2024 at 1:16 PM Jim Jones wrote:
> In case all columns of a record have been set to null due to data type
> incompatibility, should we insert it at all?
Yes. In particular not all columns in the table need be specified in the
copy command so while the parsed input data is all n
Hi!
On 12.02.24 01:00, jian he wrote:
> attached v2.
> syntax: `on_error set_to_null`
> based on upthread discussion, now if you specified `on_error
> set_to_null` and your column has `not
> null` constraint, we convert the error field to null, so it may error
> while bulk inserting for violating
attached v2.
syntax: `on_error set_to_null`
based on upthread discussion, now if you specified `on_error
set_to_null` and your column has `not
null` constraint, we convert the error field to null, so it may error
while bulk inserting for violating NOT NULL constraint.
From c95bb7b7c072f510b9a606957
On Mon, 5 Feb 2024 14:26:46 +0800
jian he wrote:
> On Mon, Feb 5, 2024 at 10:29 AM torikoshia wrote:
> >
> > Hi,
> >
> > On 2024-02-03 15:22, jian he wrote:
> > > The idea of on_error is to tolerate errors, I think.
> > > if a column has a not null constraint, let it cannot be used with
> > > (o
On Tue, Feb 6, 2024 at 3:46 PM Yugo NAGATA wrote:
>
> On Tue, 06 Feb 2024 09:39:09 +0900 (JST)
> Kyotaro Horiguchi wrote:
>
> > At Mon, 5 Feb 2024 17:22:56 +0900, Yugo NAGATA wrote
> > in
> > > On Mon, 05 Feb 2024 11:28:59 +0900
> > > torikoshia wrote:
> > >
> > > > > Based on this, I've made
On Tue, 06 Feb 2024 09:39:09 +0900 (JST)
Kyotaro Horiguchi wrote:
> At Mon, 5 Feb 2024 17:22:56 +0900, Yugo NAGATA wrote in
> > On Mon, 05 Feb 2024 11:28:59 +0900
> > torikoshia wrote:
> >
> > > > Based on this, I've made a patch.
> > > > based on COPY Synopsis: ON_ERROR 'error_action'
> > >
At Mon, 5 Feb 2024 17:22:56 +0900, Yugo NAGATA wrote in
> On Mon, 05 Feb 2024 11:28:59 +0900
> torikoshia wrote:
>
> > > Based on this, I've made a patch.
> > > based on COPY Synopsis: ON_ERROR 'error_action'
> > > on_error 'null', the keyword NULL should be single quoted.
> >
> > As you ment
On Mon, 05 Feb 2024 11:28:59 +0900
torikoshia wrote:
> > Based on this, I've made a patch.
> > based on COPY Synopsis: ON_ERROR 'error_action'
> > on_error 'null', the keyword NULL should be single quoted.
>
> As you mentioned, single quotation seems a little odd..
>
> I'm not sure what is the
On Mon, Feb 5, 2024 at 10:29 AM torikoshia wrote:
>
> Hi,
>
> On 2024-02-03 15:22, jian he wrote:
> > The idea of on_error is to tolerate errors, I think.
> > if a column has a not null constraint, let it cannot be used with
> > (on_error 'null')
>
> > + /*
> > +* we can specify on_e
Hi,
On 2024-02-03 15:22, jian he wrote:
The idea of on_error is to tolerate errors, I think.
if a column has a not null constraint, let it cannot be used with
(on_error 'null')
+ /*
+* we can specify on_error 'null', but it can only apply to
columns
+* don't have not n
The idea of on_error is to tolerate errors, I think.
if a column has a not null constraint, let it cannot be used with
(on_error 'null')
Based on this, I've made a patch.
based on COPY Synopsis: ON_ERROR 'error_action'
on_error 'null', the keyword NULL should be single quoted.
demo:
COPY check_i
On Fri, 26 Jan 2024 08:08:29 -0700
"David G. Johnston" wrote:
> Hi,
>
> The option choice of "ignore" in the COPY ON_ERROR clause seems overly
> generic. There would seem to be two relevant ways to ignore bad column
> input data - drop the entire row or just set the column value to null. I
> c
On Sun, Jan 28, 2024 at 4:51 PM jian he wrote:
> On Fri, Jan 26, 2024 at 11:09 PM David G. Johnston
> wrote:
> >
> > Hi,
> >
> > The option choice of "ignore" in the COPY ON_ERROR clause seems overly
> generic. There would seem to be two relevant ways to ignore bad column
> input data - drop th
On Fri, Jan 26, 2024 at 11:09 PM David G. Johnston
wrote:
>
> Hi,
>
> The option choice of "ignore" in the COPY ON_ERROR clause seems overly
> generic. There would seem to be two relevant ways to ignore bad column input
> data - drop the entire row or just set the column value to null. I can s
Hi,
The option choice of "ignore" in the COPY ON_ERROR clause seems overly
generic. There would seem to be two relevant ways to ignore bad column
input data - drop the entire row or just set the column value to null. I
can see us wanting to provide the set to null option and in any case having
t
57 matches
Mail list logo
