Horton

Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

torikoshia <torikoshia@oss.nttdata.com>

View thread
From: torikoshia <torikoshia@oss.nttdata.com>
To: Andres Freund <andres@anarazel.de>
Cc: tgl@sss.pgh.pa.us, Daniel Gustafsson <daniel@yesql.se>, Damir Belyalov <dam.bel07@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Danil Anisimow <anisimow.d@gmail.com>, Nikita Malakhov <HukuToc@gmail.com>, a.lepikhov@postgrespro.ru
Date: 2023-03-24T09:27:08Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. doc: Fix COPY ON_ERROR option syntax synopsis.

  2. Disallow specifying ON_ERROR option without value.

  3. Rename COPY option from SAVE_ERROR_TO to ON_ERROR

  4. Fix spelling in notice

  5. Add new COPY option SAVE_ERROR_TO

On 2023-03-23 02:50, Andres Freund wrote:
> Hi,
> 
> Tom, see below - I wonder if should provide one more piece of 
> infrastructure
> around the saved error stuff...
> 
> 
> Have you measured whether this has negative performance effects when 
> *NOT*
> using the new option?
> 
> 
> As-is this does not work with FORMAT BINARY - and converting the binary 
> input
> functions to support soft errors won't happen for 16. So I think you 
> need to
> raise an error if BINARY and IGNORE_DATATYPE_ERRORS are specified.
> 
> 
> On 2023-03-22 22:34:20 +0900, torikoshia wrote:
>> @@ -985,9 +986,28 @@ CopyFrom(CopyFromState cstate)
>> 
>>  		ExecClearTuple(myslot);
>> 
>> +		if (cstate->opts.ignore_datatype_errors)
>> +		{
>> +			escontext.details_wanted = true;
>> +			cstate->escontext = escontext;
>> +		}
> 
> I think it might be worth pulling this out of the loop. That does mean 
> you'd
> have to reset escontext.error_occurred after an error, but that doesn't 
> seem
> too bad, you need to do other cleanup anyway.
> 
> 
>> @@ -956,10 +957,20 @@ NextCopyFrom(CopyFromState cstate, ExprContext 
>> *econtext,
>>  				values[m] = ExecEvalExpr(defexprs[m], econtext, &nulls[m]);
>>  			}
>>  			else
>> -				values[m] = InputFunctionCall(&in_functions[m],
>> -											  string,
>> -											  typioparams[m],
>> -											  att->atttypmod);
>> +				/* If IGNORE_DATATYPE_ERRORS is enabled skip rows with datatype 
>> errors */
>> +				if (!InputFunctionCallSafe(&in_functions[m],
>> +										   string,
>> +										   typioparams[m],
>> +										   att->atttypmod,
>> +										   (Node *) &cstate->escontext,
>> +										   &values[m]))
>> +				{
>> +					cstate->ignored_errors++;
>> +
>> +					ereport(WARNING,
>> +							errmsg("%s", cstate->escontext.error_data->message));
> 
> That isn't right - you loose all the details of the message. As is 
> you'd also
> leak the error context.
> 
> I think the best bet for now is to do something like
>     /* adjust elevel so we don't jump out */
>     cstate->escontext.error_data->elevel = WARNING;
>     /* despite the name, this won't raise an error if elevel < ERROR */
>     ThrowErrorData(cstate->escontext.error_data);

Thanks for your reviewing!
I'll try to fix it this way for the time being.

> I wonder if we ought to provide a wrapper for this? It could e.g. know 
> to
> mention the original elevel and such?

-- 
Regards,

--
Atsushi Torikoshi
NTT DATA CORPORATION