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
signature.asc
Description: PGP signature
