On Fri, Jun 05, 2026 at 08:59:17PM +0900, Etsuro Fujita wrote: > I created the patch to add that support on top of the patch I sent in > a previous email, which I'm attaching along with the base patch. It's > the same as before, except that I fixed a typo in docs pointed out by > Michael-san off-list.
Splitting the patch set into two pieces, as of one for the
introduction of the remotely_inherited option defaulting to the
current HEAD behavior, and one for the modification of the IMPORT
FOREIGN SCHEMA, makes sense here. A backpatch of the first patch is a
no-brainer, so as it gives a way for users to switch to the new
behavior at will. I am however on edge regarding the wisdom of
backpatching the second patch, which would force a new behavior of the
postgres_fdw implementation for partitioned tables (based on my
read of the test with "t4") and INHERIT ("t6", "t8") depending on the
relkind or the property of the relation imported. I can't help but
wonder why you don't take a different, slightly more conservative
approach on HEAD and the stable branches with a new option that can be
specified to the IMPORT FOREIGN SCHEMA query, to make the choice of
setting remotely_inherited for a relation imported an opt-in or
opt-out choice.
I would not object with a switch of the default behavior across major
versions, and perhaps my argument is not sound enough, but I've learnt
my share when it comes to be careful with changes like the one you may
introduce here across a minor release, particularly knowing that
remotely_inherited *can* be set on an option basis when creating a
table *or* when importing a schema. The designs we have for these
queries allows this kind of flexibility.
--
Michael
signature.asc
Description: PGP signature
