On 2024-03-07 13:00, Michael Paquier wrote:
> On Wed, Mar 06, 2024 at 07:32:28PM +0530, Bharath Rupireddy wrote:
>> 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.
>
> The approach looks sensible seen from here.
>
> + LOG_VERBOSITY [ <replaceable
> class="parameter">boolean</replaceable> ]
> [...]
> + <term><literal>LOG_VERBOSITY</literal></term>
> + <listitem>
> + <para>
> + Sets the verbosity of logged messages by <command>COPY</command>
> + command. As an example, see its usage for
> + <command>COPY FROM</command> command's
> <literal>ON_ERROR</literal>
> + clause with <literal>ignore</literal> option.
> + </para>
> + </listitem>
>
> Is a boolean the best interface for the end-user, though? Maybe
> something like a "mode" value would speak more than a yes/no from the
> start, say a "default" mode to emit only the last LOG and a "verbose"
> for the whole set in the case of ON_ERROR? That could use an enum
> from the start internally, but that's an implementation detail.
>
> Describing what gets logged in the paragraph of ON_ERROR sounds fine,
> especially if in the future more logs are added depending on other
> options. That's an assumption at this stage, of course.
>
> I am adding Alexander Korotkov in CC, as the original committer of
> 9e2d8701194f, as I assume that he may want to chime in this
> discussion.
>
> Torikoshi-san or others, if you have any comments about the interface,
> feel free.
Thanks.
Maybe I'm overly concerned, but I'm a little concerned about whether the
contents of this output can really be called verbose, since it does not
output the actual soft error message that occurred, but only the row and
column where the error occurred.
Since the soft error mechanism can at least output the contents of soft
errors in the server log [1], it might be a good idea to use something
like a 'mode' value instead of boolean as Michael-san suggested, so that
the log output contents can be adjusted at multiple levels.
[1]
https://www.postgresql.org/message-id/20230322175000.qbdctk7bnmifh5an%40awork3.anarazel.de
--
Regards,
--
Atsushi Torikoshi
NTT DATA Group Corporation