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 |
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 |