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


Reply via email to