Re: on_error table, saving error info to a table
jian he <jian.universality@gmail.com>
From: jian he <jian.universality@gmail.com>
To: Nishant Sharma <nishant.sharma@enterprisedb.com>
Cc: Kirill Reshke <reshkekirill@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-05-06T08:08:33Z
Lists: pgsql-hackers
Attachments
- v9-0002-COPY-FROM-on_error-table-error_table-errtbl.patch (text/x-patch)
- v9-0001-export-ExecInsert-and-other-friends-function.patch (text/x-patch)
On Wed, Apr 22, 2026 at 10:11 AM jian he <jian.universality@gmail.com> wrote: > > Hi, V8 is attached. > > I've refactored a significant portion of the code. Now the new syntax is: > > COPY FROM (ON_ERROR TABLE, ERROR_TABLE err_tbl); > > We now produce a ModifyTableState and ResultRelInfo node, form the slot, and > then use table_tuple_insert() + ExecInsertIndexTuples() to insert the error > metadata into the ERROR_TABLE. > > This is very similar to the normal ExecInsert() path. Since the ERROR_TABLE is a > user-defined table, we enforce the a lot of restriction, > in CopyFromErrorTableCheck, we have comments like: > + Actually, We can export ExecInsert, construct a ModifyTableContext, and let ExecInsert do the remaining job. This would be neater. V9-0001: Export ExecInsert, ExecSetupTransitionCaptureState, fireBSTriggers, fireASTrigger. v9-0002: Introduce a (ModifyTableContext *) field in CopyFromStateData. Initialize all useful subordinate structures, including such as ModifyTableState, EState, and ModifyTableState->ResultRelInfo. Set cstate->escontext->details_wanted to true to ensure that all input conversion error metadata is captured in cstate->escontext. Use this metadata to construct a TupleTableSlot, and then delegate the remaining processing to ExecInsert. Before calling ExecInsert() to insert error metadata into the ERROR_TABLE, we must first populate a ModifyTableState, similar to how it is done in ExecInitModifyTable. ERROR_TABLE currently cannot be a partitioned table there is no need to call ExecSetupPartitionTupleRouting. ERROR_TABLE cannot be a foreign table, ExecInitModifyTable foreign table related initialization handling is not needed. ERROR_TABLE does not support Row-Level Security (RLS), we do not need to handle ModifyTable->withCheckOptionLists. For the INSERT code path, we also do not need to worry about EvalPlanQual. By comparing side-by-side with ExecInitModifyTable, it is ok to populate the necessary information for the ERROR_TABLE using the following functions: ExecInitRangeTable, ExecInitResultRelation, ExecOpenIndices, and CheckValidResultRel. This will allow the ERROR_TABLE to safely use ExecInsert(). -- jian https://www.enterprisedb.com/