Re: TRUNCATE on foreign table

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: Kohei KaiGai <kaigai(at)heterodb(dot)com>, Kazutaka Onishi <onishi(at)heterodb(dot)com>, Zhihong Yu <zyu(at)yugabyte(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Subject: Re: TRUNCATE on foreign table
Date: 2021-04-16 02:54:16
Message-ID: 2ec345ad-9a7b-a21f-8a1b-04c0537ea9b8@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
truncate_foreign_table_dont_pass_only_clause.patch text/plain 15.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2021-04-16 02:56:05 Re: Bogus collation version recording in recordMultipleDependencies
Previous Message Justin Pryzby 2021-04-16 02:52:18 Re: Replication slot stats misgivings