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:
+
+/*
+ * The error saving table must be a plain table and is subject to the following
+ * restrictions: it cannot have foreign key constraints; nor can it have column
+ * DEFAULT values, triggers, rules, or row-level security policies.
+ *
+ * These restrictions are necessary to allow the use of table_tuple_insert();
+ * otherwise, the executor would need to perform additional validation (e.g.
+ * foreign key constraint check) for each inserted error row.
+ */
+static void
+CopyFromErrorTableCheck(Relation relation)
I also add some dummy tests like:
+-- Direct modification of system catalog composite type 'copy_error_saving' is
+-- not permitted.
+ALTER TYPE copy_error_saving ADD ATTRIBUTE b text;
+ALTER TYPE copy_error_saving DROP ATTRIBUTE userid;
+ALTER TYPE copy_error_saving RENAME ATTRIBUTE userid to userid1;
+ALTER TYPE copy_error_saving ALTER ATTRIBUTE userid SET DATA TYPE OID8;
To demonstrate that the system's composite copy_error_saving attribute is fixed.
Similarly, ERROR_TABLE data definition is fixed.
--
jian
https://www.enterprisedb.com/
