Re: on_error table, saving error info to a table

On Wed, 22 Oct 2025 at 10:15, jian he <jian.universality@gmail.com> wrote:
>
> hi.
>
> The previous discussion mentioned using built-in typed tables for the
> error saving table.
> It's doable.
>
> first create an build-in composite type in system_functions.sql:
> CREATE TYPE copy_error_saving AS(
>     userid    oid,
>     copy_tbl  oid,
>     filename  text COLLATE "C",
>     lineno    bigint,
>     line      text COLLATE "C",
>     colname   text COLLATE "C",
>     raw_field_value text COLLATE "C",
>     err_message     text COLLATE "C",
>     err_detail      text COLLATE "C",
>     errorcode       text COLLATE "C"
> );
>
> then we can use it to create a table like:
> CREATE TABLE error_saving_table OF copy_error_saving;
>
> The downside of this:
> If the pg_catalog composite (type copy_error_saving) were to change,
> it could lead to potential compatibility issues.
> We need to be confident that copy_error_saving definitions are
> unlikely to occur in the future.
>
> For the above type copy_error_saving, I am wondering, do we aslo need
> add a timestamptz field like "starttime" to indicate COPY beginning time.
>
> anyway, please take a look at the attached patch.
> It introduces a built-in composite type, allowing users to simply use
> CREATE TABLE x OF copy_error_saving
> to create a table for storing COPY FROM error-related information.

Hi!
I actually wonder if we should change security context to on_err_table
owner before

> + simple_heap_insert(cstate->error_saving, tuple);

I mean, without this, the whole feature looks like a recipe for CVE. I
mean, something like inserting invalid rows into a table to make a
user, who executes that INSERT to do an 'err_tbl' insert instead,
which will execute BEFORE INSERT TRIGGER, which in turn will alter
something... Like 'alter user ... with superuser'?

I do not have a complete real-life scenario though.


-- 
Best regards,
Kirill Reshke