On Thu, 18 Sep 2025 14:37:29 +0900 Fujii Masao <[email protected]> wrote:
> On Thu, Sep 18, 2025 at 10:22 AM Yugo Nagata <[email protected]> wrote: > > That makes sense. How about rewriting this like: > > > > However, if the --continue-on-error option is specified and the error > > occurs in > > an SQL command, the client does not abort and proceeds to the next > > transaction regardless of the error. These cases are reported as "other > > failures" > > in the output. Note that if the error occurs in a meta-command, the client > > will > > still abort even when this option is specified. > > How about phrasing it like this, based on your version? > > ---------------------------- > A client's run is aborted in case of a serious error; for example, the > connection with the database server was lost or the end of script was reached > without completing the last transaction. The client also aborts > if a meta-command fails, or if an SQL command fails for reasons other than > serialization or deadlock errors when --continue-on-error is not specified. > With --continue-on-error, the client does not abort on such SQL errors > and instead proceeds to the next transaction. These cases are reported > as "other failures" in the output. If the error occurs in a meta-command, > however, the client still aborts even when this option is specified. > ---------------------------- I'm fine with that. This version is clearer. Regards, Yugo Nagata -- Yugo Nagata <[email protected]>
