On Mon, Dec 16, 2024 at 7:50 PM Nishant Sharma
wrote:
>
>
> 1) The new switch logic does not look correct to me. It will pass for
> a failing scenario. I think you can use v3's logic instead with below
> changes:-
>
> a)
> while (HeapTupleIsValid(atup = systable_getnext(ascan))) -->
> while (HeapT
On Mon, 16 Dec 2024 at 16:50, Nishant Sharma
wrote:
> Also, I think Andrew's suggestion can resolve the concern me and Krill
> had on forcing users to create tables with correct column names and
> numbers. Also, will make error table checking simpler. No need for the
> above kind of checks.
+1 on
On Fri, Dec 13, 2024 at 1:57 PM jian he wrote:
> On Wed, Dec 11, 2024 at 7:41 PM Nishant Sharma
> wrote:
> >
> > Thanks for the v3 patch!
> >
> > Please find review comments on v3:-
> >
> > 1) I think no need to change the below if condition, we can keep
> > it the way it was before i.e with
> >
On Wed, Dec 11, 2024 at 7:41 PM Nishant Sharma
wrote:
>
> Thanks for the v3 patch!
>
> Please find review comments on v3:-
>
> 1) I think no need to change the below if condition, we can keep
> it the way it was before i.e with
> "cstate->opts.on_error != COPY_ON_ERROR_STOP" and we
> add a new err
On 2024-12-02 Mo 11:28 PM, jian he wrote:
On Tue, Nov 5, 2024 at 6:30 PM Nishant Sharma
wrote:
Thanks for the v2 patch!
I see v1 review comments got addressed in v2 along with some
further improvements.
1) v2 Patch again needs re-base.
2) I think we need not worry whether table name is uni
Thanks for the v3 patch!
Please find review comments on v3:-
1) I think no need to change the below if condition, we can keep
it the way it was before i.e with
"cstate->opts.on_error != COPY_ON_ERROR_STOP" and we
add a new error ereport the way v3 has. Because for
cstate->opts.on_error as COPY_ON
On Tue, 3 Dec 2024 at 09:29, jian he wrote:
>
> On Tue, Nov 5, 2024 at 6:30 PM Nishant Sharma
> wrote:
> >
> > Thanks for the v2 patch!
> >
> > I see v1 review comments got addressed in v2 along with some
> > further improvements.
> >
> > 1) v2 Patch again needs re-base.
> >
> > 2) I think we nee
On Tue, Nov 5, 2024 at 6:30 PM Nishant Sharma
wrote:
>
> Thanks for the v2 patch!
>
> I see v1 review comments got addressed in v2 along with some
> further improvements.
>
> 1) v2 Patch again needs re-base.
>
> 2) I think we need not worry whether table name is unique or not,
> table name can be
Thanks for the v2 patch!
I see v1 review comments got addressed in v2 along with some
further improvements.
1) v2 Patch again needs re-base.
2) I think we need not worry whether table name is unique or not,
table name can be provided by user and we can check if it does
not exists then simply we
On Mon, Jul 15, 2024 at 1:42 PM Nishant Sharma
wrote:
>
> Thanks for the patch!
>
> I was not able to understand why we need a special error table for COPY?
> Can't we just log it in a new log error file for COPY in a proper format? Like
> using table approach, PG would be unnecessarily be utilisi
Thanks for the patch!
I was not able to understand why we need a special error table for COPY?
Can't we just log it in a new log error file for COPY in a proper format?
Like
using table approach, PG would be unnecessarily be utilising its resources
like
extra CPU to format the data in pages to sto
11 matches
Mail list logo
