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
