Re: TRUNCATE on foreign tables

Поиск
Список
Период
Сортировка
От Kohei KaiGai
Тема Re: TRUNCATE on foreign tables
Дата
Msg-id CAOP8fzbrQcPgC=DhJEHbFPzVoUXKMcFf=r8kKjdSLnv0oqr3DA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: TRUNCATE on foreign tables  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: TRUNCATE on foreign tables
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: 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
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: [PATCH] Atomic pgrename on Windows