Re: Add new error_action COPY ON_ERROR "log"

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, jian(dot)universality(at)gmail(dot)com, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add new error_action COPY ON_ERROR "log"
Date: 2024-03-06 14:02:28
Message-ID: CALj2ACU=eSs+2WEmteyuqL7-2cstwjFKLD=ukZy+Tg4RZ=DQCw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 5, 2024 at 4:48 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Mon, Mar 04, 2024 at 05:00:00AM +0530, Bharath Rupireddy wrote:
> > How about an extra option to error_action ignore-with-verbose which is
> > similar to ignore but when specified emits one NOTICE per malformed
> > row? With this, one can say COPY x FROM stdin (ON_ERROR
> > ignore-with-verbose);.
> >
> > Alternatively, we can think of adding a new option verbose altogether
> > which can be used for not only this but for reporting some other COPY
> > related info/errors etc. With this, one can say COPY x FROM stdin
> > (VERBOSE on, ON_ERROR ignore);.
>
> I would suggest a completely separate option, because that offers more
> flexibility as each option has a separate meaning. My main concern in
> using one option to control them all is that one may want in the
> future to be able to specify more combinations of actions at query
> level, especially if more modes are added to the ON_ERROR mode. One
> option would prevent that.
>
> Perhaps ERROR_VERBOSE or ERROR_VERBOSITY would be better names, but
> I'm never wedded to my naming suggestions. Bad history with the
> matter.

+1 for a separate option and LOG_VERBOSITY seemed a better and generic
naming choice. Because, the ON_ERROR ignore isn't actually an error
per se IMO.

> > There's also another way of having a separate GUC, but -100 from me
> > for it. Because, it not only increases the total number of GUCs by 1,
> > but also might set a wrong precedent to have a new GUC for controlling
> > command level outputs.
>
> What does this have to do with GUCs? The ON_ERROR option does not
> have one.

My thought was to have a separate GUC for deciding log level for COPY
command messages/errors similar to log_replication_commands. But
that's a no-go for sure when compared with a separate option.

Please see the attached v4 patch. If it looks good, I can pull
LOG_VERBOSITY changes out into 0001 and with 0002 containing the
detailed messages for discarded rows.

--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

Attachment Content-Type Size
v4-0001-Add-detailed-info-when-COPY-skips-soft-errors.patch application/x-patch 7.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Denis Laxalde 2024-03-06 14:03:20 Re: [EXTERNAL] Re: Add non-blocking version of PQcancel
Previous Message Andrey M. Borodin 2024-03-06 13:49:48 Re: CF entries for 17 to be reviewed