Re: TRUNCATE on foreign table

On 2021/04/16 9:15, Bharath Rupireddy wrote:
> On Thu, Apr 15, 2021 at 8:19 PM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)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.

We are still discussing whether RESTRICT option should be pushed down to
a foreign data wrapper. But ISTM at least we could reach the consensus about
the drop of extra information for each foreign table. So what about applying
the attached patch and remove the extra information at first?

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION