Re: TRUNCATE on foreign table
От | Fujii Masao |
---|---|
Тема | Re: TRUNCATE on foreign table |
Дата | |
Msg-id | d5df2e94-f643-6409-5cd4-fa1c2ebd41fa@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: TRUNCATE on foreign table (Kohei KaiGai <kaigai@heterodb.com>) |
Ответы |
Re: TRUNCATE on foreign table
|
Список | pgsql-hackers |
On 2021/04/08 13:43, Kohei KaiGai wrote: > In case when a local table (with no children) has same contents, > TRUNCATE command > witll remove the entire table contents. But if there are local child tables that inherit the local parent table, and TRUNCATE ONLY <parent table> is executed, onlythe contents in the parent will be truncated. I was thinking that this behavior should be applied to the foreign tablewhose remote (parent) table have remote child tables. So what we need to reach the consensus is; how far ONLY option affects. Please imagine the case where we have (1) local parent table, also foreign table of remote parent table (2) local child table, inherits local parent table (3) remote parent table (4) remote child table, inherits remote parent table I think that we agree all (1), (2), (3) and (4) should be truncated if local parent table (1) is specified without ONLY inTRUNCATE command. OTOH, if ONLY is specified, we agree that at least local child table (2) should NOT be truncated. So the remaining point is; remote tables (3) and (4) should be truncated or not when ONLY is specified? You seem to arguethat both should be truncated by removing extra list. I was thinking that only remote parent table (3) should be truncated.That is, IMO we should treat the truncation on foreign table as the same as that on its forein data source. Other people might think neither (3) nor (4) should be truncated in that case because ONLY should affect only the table directlyspecified in TRUNCATE command, i.e., local parent table (1). For now this also looks good to me. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: