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.
