Re: TRUNCATE on foreign tables - Mailing list pgsql-hackers

From Kohei KaiGai
Subject Re: TRUNCATE on foreign tables
Date
Msg-id CAOP8fzbrQcPgC=DhJEHbFPzVoUXKMcFf=r8kKjdSLnv0oqr3DA@mail.gmail.com
Whole thread Raw
In response to Re: TRUNCATE on foreign tables  (Michael Paquier <michael@paquier.xyz>)
Responses Re: TRUNCATE on foreign tables  (Kohei KaiGai <kaigai@heterodb.com>)
List pgsql-hackers
2020年1月7日(火) 16:03 Michael Paquier <michael@paquier.xyz>:
>
> On Mon, Jan 06, 2020 at 04:32:39PM -0500, Stephen Frost wrote:
> > RESTRICT, yes.  I don't know about ONLY being sensible as we don't
> > really deal with inheritance and foreign tables very cleanly today, as I
> > said up-thread, so I'm not sure if we really want to put in the effort
> > that it'd require to figure out how to make ONLY make sense.
>
> True enough.
>
> > The question about how to handle IDENTITY is a good one.  I suppose
> > we could just pass that down and let the FDW sort it out..?
>
> Looking at the code, ExecuteTruncateGuts() passes down restart_seqs,
> so it sounds sensible to me to just pass down that to the FDW
> callback and the callback decide what to do.
>
It looks to me the local sequences owned by a foreign table shall be restarted
by the core, regardless of relkind of the owner relation. So, even if FDW driver
is buggy, consistency of the local database is kept, right?
Indeed, "restart_seqs" flag is needed to propagate the behavior, however,
it shall be processed on the remote side via the secondary "TRUNCATE" command.
Is it so sensitive?

Best regards,
--
HeteroDB, Inc / The PG-Strom Project
KaiGai Kohei <kaigai@heterodb.com>



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Assert failure due to "drop schema pg_temp_3 cascade" fortemporary tables and \d+ is not showing any info after drooping temp table schema
Next
From: Tomas Vondra
Date:
Subject: Re: [PATCH] Atomic pgrename on Windows