Re: TRUNCATE on foreign table
От | Bharath Rupireddy |
---|---|
Тема | Re: TRUNCATE on foreign table |
Дата | |
Msg-id | CALj2ACUvkyyEP0YM5WPGfgXtTqYTMBE2Jzy8C1oX6_DcHTxf=g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: TRUNCATE on foreign table (Fujii Masao <masao.fujii@oss.nttdata.com>) |
Ответы |
Re: TRUNCATE on foreign table
|
Список | pgsql-hackers |
On Thu, Apr 15, 2021 at 8:19 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote: > On 2021/04/14 12:54, Bharath Rupireddy wrote: > > IMHO, we can push all the TRUNCATE options (ONLY, RESTRICTED, CASCADE, > > RESTART/CONTINUE IDENTITY), because it doesn't have any major > > challenge(implementation wise) unlike pushing some clauses in > > SELECT/UPDATE/DELETE and we already do this on the master. It doesn't > > look good and may confuse users, if we push some options and restrict > > others. We should have an explicit note in the documentation saying we > > push all these options to the remote server. We can leave it to the > > user to write TRUNCATE for foreign tables with the appropriate > > options. If somebody complains about a problem that they will face > > with this behavior, we can revisit. > > That's one of the options. But I'm afraid it's hard to drop (revisit) > the feature once it has been released. So if there is no explicit > use case for that, basically I'd like to drop that before release > like we agree to drop unused TRUNCATE_REL_CONTEXT_CASCADING. Thanks. Looks like the decision is going in the direction of restricting those options, I will withdraw my point. With Regards, Bharath Rupireddy. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: