| From: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
|---|---|
| To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
| Cc: | Kazutaka Onishi <onishi(at)heterodb(dot)com>, Zhihong Yu <zyu(at)yugabyte(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Kohei KaiGai <kaigai(at)heterodb(dot)com> |
| Subject: | Re: TRUNCATE on foreign table |
| Date: | 2021-02-09 12:30:27 |
| Message-ID: | CAExHW5sb6jFFB4MBw+fHkSs0pKzD6=Ux=08kfiPN1_gEh4QSKg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Feb 9, 2021 at 5:49 PM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>
> On Tue, Feb 9, 2021 at 5:31 PM Ashutosh Bapat
> <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
> > Why would one want to truncate a foreign table instead of truncating
> > actual table wherever it is?
>
> I think when the deletion on foreign tables (which actually deletes
> rows from the remote table?) is allowed, it does make sense to have a
> way to truncate the remote table via foreign table. Also, it can avoid
> going to each and every remote server and doing the truncation
> instead.
DELETE is very different from TRUNCATE. Application may want to DELETE
based on a join with a local table and hence it can not be executed on
a foreign server. That's not true with TRUNCATE.
--
Best Wishes,
Ashutosh Bapat
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matthias van de Meent | 2021-02-09 12:32:33 | Re: Improvements and additions to COPY progress reporting |
| Previous Message | Alvaro Herrera | 2021-02-09 12:23:53 | Re: pg_replication_origin_drop API potential race condition |