On Wed, Oct 22, 2025 at 10:45 AM jian he <[email protected]>
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;
>
Exactly. This is what I was trying to convey about the suggestion by
Andrew.
Please find review comments on v7:-
1) I think we can improve below, and can avoid 3 conditional check
to only one
>if (cstate->escontext->error_data->detail == NULL)
> err_detail = NULL;
>else
> err_detail = cstate->escontext->error_data->detail;
>
>values[j] = err_detail ? CStringGetTextDatum(err_detail) : (Datum) 0;
>isnull[j++] = err_detail ? false : true;
TO
>if (cstate->escontext->error_data->detail == NULL)
>{
> values[j] = (Datum) 0;
> isnull[j++] = true;
>}
> else
> values[j++] =
CStringGetTextDatum(cstate->escontext->error_data->detail);
2) We can have "#define ERROR_TBL_COLUMNS 10" instead of
hardcoded 10 in file copyfromparse.c. Because now, it is used only
in copyfromparse.c.
3) Do we need a 'j' variable to assign data to values[j]? I see in src
code that hard coded numbers are directly used in other places.
Like values[0] = data1; values[1] = data2, so on. With this we can
avoid j++ execution cycles.
Regards,
Nishant Sharma.
EDB, Pune.
https://www.enterprisedb.com/
