Hi, On Thu, Jan 18, 2024 at 5:33 PM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Thu, Jan 18, 2024 at 4:59 PM Alexander Korotkov <aekorot...@gmail.com> > wrote: > > > > On Thu, Jan 18, 2024 at 4:16 AM torikoshia <torikos...@oss.nttdata.com> > > wrote: > > > On 2024-01-18 10:10, jian he wrote: > > > > On Thu, Jan 18, 2024 at 8:57 AM Masahiko Sawada <sawada.m...@gmail.com> > > > > wrote: > > > >> On Thu, Jan 18, 2024 at 6:38 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > > >> > Kyotaro-san's suggestion isn't bad, though I might shorten it to > > > >> > error_action {error|ignore|log} (or perhaps "stop" instead of > > > >> > "error")? > > > >> > You will need a separate parameter anyway to specify the destination > > > >> > of "log", unless "none" became an illegal table name when I wasn't > > > >> > looking. I don't buy that one parameter that has some special values > > > >> > while other values could be names will be a good design. Moreover, > > > >> > what if we want to support (say) log-to-file along with log-to-table? > > > >> > Trying to distinguish a file name from a table name without any other > > > >> > context seems impossible. > > > >> > > > >> I've been thinking we can add more values to this option to log errors > > > >> not only to the server logs but also to the error table (not sure > > > >> details but I imagined an error table is created for each table on > > > >> error), without an additional option for the destination name. The > > > >> values would be like error_action {error|ignore|save-logs|save-table}. > > > >> > > > > > > > > another idea: > > > > on_error {error|ignore|other_future_option} > > > > if not specified then by default ERROR. > > > > You can also specify ERROR or IGNORE for now. > > > > > > > > I agree, the parameter "error_action" is better than "location". > > > > > > I'm not sure whether error_action or on_error is better, but either way > > > "error_action error" and "on_error error" seems a bit odd to me. > > > I feel "stop" is better for both cases as Tom suggested. > > > > OK. What about this? > > on_error {stop|ignore|other_future_option} > > where other_future_option might be compound like "file 'copy.log'" or > > "table 'copy_log'". > > +1 >
I realized that ON_ERROR syntax synoposis in the documentation is not correct. The option doesn't require the value to be quoted and the value can be omitted. The attached patch fixes it. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
0001-doc-Fix-COPY-ON_ERROR-option-syntax-synopsis.patch
Description: Binary data