| From: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
|---|---|
| To: | torikoshia <torikoshia(at)oss(dot)nttdata(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Add new COPY option REJECT_LIMIT |
| Date: | 2024-07-19 13:03:57 |
| Message-ID: | a873643c-e7d1-456c-b16b-6162ab698036@oss.nttdata.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2024/07/17 22:21, torikoshia wrote:
> On 2024-07-03 02:07, Fujii Masao wrote:
>> However, if we support REJECT_LIMIT, I'm not sure if the ON_ERROR option is still necessary.
>
> I remembered another reason for the necessity of ON_ERROR.
>
> ON_ERROR defines how to behave when encountering an error and it just accepts 'ignore' and 'stop' currently, but is expected to support other options such as saving details of errors to a table[1].
Wouldn't it be better to separate the option specifying where
error details are output from the ON_ERROR option
(which determines behavior when encountering errors)?
"table" seems valid for both ON_ERROR=ignore and ON_ERROR=stop.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2024-07-19 13:04:40 | How can udf c function return table, not the rows? |
| Previous Message | Amit Kapila | 2024-07-19 12:44:55 | Re: Slow catchup of 2PC (twophase) transactions on replica in LR |