On Mon, Jan 27, 2020 at 11:08:36PM +0900, Kohei KaiGai wrote:
> Hmm. Do we need to deliver another list to inform why these relations are
> trundated?
I got to think more about this one, and being able to control ONLY on
a per-relation basis would be the least surprising approach for the
commands generated. But at least this avoids truncating a full
inheritance tree on a remote cluster even if ONLY is specified
locally. Note that I'd like to assume that most applications have a
1:1 mapping in their schemas between a local and remote cluster, but
that's most likely not always the case ;)
> If callback is invoked with a foreign-relation that is specified by TRUNCATE
> command with ONLY, it seems to me reasonable that remote TRUNCATE
> command specifies the relation on behalf of the foreign table with ONLY.
>
> So, if ExecForeignTruncate() has another list to inform the context for each
> relation, postgres_fdw can build proper remote query that may specify the
> remote tables with ONLY-clause.
Yeah, TRUNCATE can specify ONLY on a per-table basis, so having a
second list makes sense. Then in the FDW, just make sure to
elog(ERROR) if the lengths do no match, and then use forboth() to loop
over them. One thing that you need to be careful about is that tables
which are added to the list because of inheritance should not be
marked with ONLY when generating the command to the remote.
> Regarding to the other comments, it's all Ok for me. I'll update the patch.
> And, I forgot "updatable" option at postgres_fdw. It should be checked on
> the truncate also, right?
Hmm. Good point. Being able to filter that silently through a
configuration parameter is kind of interesting. Now I think that this
should be a separate option because updatable applies to DMLs. Like,
truncatable?
For now, as the patch needs more work for its implementation, docs and
tests, I am marking it as returned with feedback.
--
Michael
