MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Thu, 18 Jan 2024 21:09:13 +0900
From: torikoshia <torikoshia@oss.nttdata.com>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: jian he <jian.universality@gmail.com>, Masahiko Sawada
 <sawada.mshk@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Kyotaro Horiguchi
 <horikyota.ntt@gmail.com>, vignesh21@gmail.com, lena.ribackina@yandex.ru,
 dam.bel07@gmail.com, zhihuifan1213@163.com, daniel@yesql.se,
 pgsql-hackers@postgresql.org, andres@anarazel.de, anisimow.d@gmail.com,
 HukuToc@gmail.com, pgsql-hackers@lists.postgresql.org,
 a.lepikhov@postgrespro.ru
Subject: Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)
In-Reply-To: 
 <CAPpHfds-WExDYWUvtBfb=Q9tjp4gcH4-noDgo6YCNhiR-DmJVw@mail.gmail.com>
References: <d73736e0614b4cf2330786b9c2ff93a5@oss.nttdata.com>
 <CAPpHfdvfpON-osWgDg-gsJGi9MnC4XdAWCdcH1vJcq9LOa97cw@mail.gmail.com>
 <762d7dd4d5aa9e5ecffec2ae6a255a28@oss.nttdata.com>
 <20240117.164859.2242646601795501168.horikyota.ntt@gmail.com>
 <CAPpHfduYDAmgccWM--A2md-zS-6zP_H41-xtUskV_daBfpAk_Q@mail.gmail.com>
 <2070915.1705527477@sss.pgh.pa.us>
 <CAD21AoD474GqjdoUkm8kU0e8xO__A-BHR1=_QyCAmAkcKoHY1w@mail.gmail.com>
 <CACJufxFyM-TPsaXPg6-b_Ps0=bnAi9xyhvVKT1UtuF-qyepEnA@mail.gmail.com>
 <350926525700756634e7c7b003fb1694@oss.nttdata.com>
 <CAPpHfds-WExDYWUvtBfb=Q9tjp4gcH4-noDgo6YCNhiR-DmJVw@mail.gmail.com>
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <ff414dce2f046dc94c52d4cd249bd57a@oss.nttdata.com>
Archived-At: 
 <https://www.postgresql.org/message-id/ff414dce2f046dc94c52d4cd249bd57a%40oss.nttdata.com>
Precedence: bulk

On 2024-01-18 16:59, Alexander Korotkov wrote:
> On Thu, Jan 18, 2024 at 4:16 AM torikoshia <torikoshia@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.mshk@gmail.com>
>> > wrote:
>> >> On Thu, Jan 18, 2024 at 6:38 AM Tom Lane <tgl@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'".

Thanks, also +1 from me.

-- 
Regards,

--
Atsushi Torikoshi
NTT DATA Group Corporation