Re: on_error table, saving error info to a table
solaimurugan vellaipandiyan <drsolaimurugan.v@gmail.com>
From: solaimurugan vellaipandiyan <drsolaimurugan.v@gmail.com>
To: jian he <jian.universality@gmail.com>
Cc: Nishant Sharma <nishant.sharma@enterprisedb.com>,
Kirill Reshke <reshkekirill@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-05-11T07:31:26Z
Lists: pgsql-hackers
Hi, I tested the v10 patch series further on current PostgreSQL HEAD. The patches applied successfully on my side, and the build/install completed without issues. I initialized a fresh cluster and verified that the built-in composite type copy_error_saving is created correctly during initdb. I re-tested the COPY functionality using malformed input data and confirmed that valid rows continue loading successfully while invalid rows are redirected into ERROR_TABLE with detailed metadata. I also tried a few additional edge cases. The self-reference protection works correctly. The following case correctly errors out: COPY err_tbl FROM STDIN WITH ( ON_ERROR table, ERROR_TABLE err_tbl ); with: cannot use relation "err_tbl" for COPY error saving while copying data to it I additionally tested ERROR_TABLE behavior with a BEFORE INSERT trigger attached to err_tbl. >From my testing, COPY still succeeds and malformed rows continue to be inserted into err_tbl even when triggers are present on the ERROR_TABLE. The trigger function also appears to execute normally during error row insertion. For example, using a trigger function with RAISE NOTICE produced: NOTICE: trigger fired for each malformed row redirected into err_tbl. Since the patch comments mention restrictions around triggers for ERROR_TABLE, I was not sure whether this current behavior is intentional or whether the trigger restriction checks are still incomplete. Overall, the executor-based integration in v10 feels cleaner and easier to follow compared to the earlier versions. Regards, Solaimurugan