Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

From: torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>, Damir Belyalov <dam(dot)bel07(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Danil Anisimow <anisimow(dot)d(at)gmail(dot)com>, Nikita Malakhov <HukuToc(at)gmail(dot)com>, a(dot)lepikhov(at)postgrespro(dot)ru, tgl(at)sss(dot)pgh(dot)pa(dot)us
Subject: Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)
Date: 2023-03-17 12:23:14
Message-ID: 9a94e684d6528dff74de5959e97032f3@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2023-03-07 18:09, Daniel Gustafsson wrote:
>> On 7 Mar 2023, at 09:35, Damir Belyalov <dam(dot)bel07(at)gmail(dot)com> wrote:
>
>> I felt just logging "Error: %ld" would make people wonder the meaning
>> of
>> the %ld. Logging something like ""Error: %ld data type errors were
>> found" might be clearer.
>>
>> Thanks. For more clearance change the message to: "Errors were found:
>> %".
>
> I'm not convinced that this adds enough clarity to assist the user. We
> also
> shouldn't use "error" in a WARNING log since the user has explicitly
> asked to
> skip rows on error, so it's not an error per se.
+1

> How about something like:
>
> ereport(WARNING,
> (errmsg("%ld rows were skipped due to data type
> incompatibility", cstate->ignored_errors),
> errhint("Skipped rows can be inspected in the database log
> for reprocessing.")));
Since skipped rows cannot be inspected in the log when
log_error_verbosity is set to terse,
it might be better without this errhint.

--
Regards,

--
Atsushi Torikoshi
NTT DATA CORPORATION

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Melih Mutlu 2023-03-17 12:24:55 Re: Allow logical replication to copy tables in binary format
Previous Message Amit Kapila 2023-03-17 12:07:18 Re: Data is copied twice when specifying both child and parent table in publication