On Fri, Jul 8, 2022 at 11:07 AM Yugo NAGATA <nag...@sraoss.co.jp> wrote: > On Fri, 08 Jul 2022 09:44:10 +0900 (JST) > Kyotaro Horiguchi <horikyota....@gmail.com> wrote: > > At Fri, 8 Jul 2022 01:06:18 +0900, Fujii Masao > > <masao.fu...@oss.nttdata.com> wrote in > > > On 2022/07/08 0:33, Tom Lane wrote:
> > > >> On 2022/06/30 10:48, Yugo NAGATA wrote: > > > >>> When a foreign table has handler but doesn't support TRUNCATE, > > > >>> an error "cannot truncate foreign table xxx" occurs. So, what > > > >>> about adding a test this message output? We can add this test > > > >>> for file_fdw because it is one of the such foreign data wrappers. > > > > This seems like a fairly pointless expenditure of test cycles > > > > to me. Perhaps more importantly, what will you do when > > > > somebody adds truncate support to that FDW? > > As Fujii-san mentioned below, file_fdw has tests for INSERT/UPDATE and > > DELETE. If somebody added DELETE to file_fdw, the test for DELETE > > rejection would be turned into a normal test of the DELETE function. > > I don't see a difference between TRUNCATE and other updating commands > > from this point of view. I agree on this point. > > > One idea is to create dummy FDW (like foreign_data.sql regression test > > > does) not supporting TRUNCATE and use it for the test. > If we want to test foreign table modifications for the FDW framework, > we will have to add such tests in foreign_data.sql, because foreign > table modifications are tested only for postgres_fdw and file_fdw. Rather than doing so, I'd vote for adding a test case to file_fdw, as proposed in the patch, because that would be much simpler and much less expensive. Best regards, Etsuro Fujita
