Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> writes:
> I noticed that the latter disallows TRUNCATE on inheritance trees that
> contain at least one child foreign table. But I think it would be
> better to allow it, with the semantics that we quietly ignore the child
> foreign tables and apply the operation to the child plain tables, which
> is the same semantics as ALTER COLUMN SET STORAGE on such inheritance
> trees. Comments welcome.
I've been working through the foreign table inheritance patch, and found
the code that makes the above happen. I don't think this is a good idea
at all. In the first place, successful TRUNCATE should leave the table
empty, not "well, we'll make it empty if we feel up to that". In the
second place, someday we might want to make TRUNCATE actually work for
foreign tables (at least for FDWs that want to support it). If we did,
we would have a backwards-compatibility hazard, because suddenly a
TRUNCATE on an inheritance tree that includes a foreign table would have
different non-error effects than before.
I think we should just throw error in this case.
BTW, the SET STORAGE comparison is bogus as well. I see no reason that
we shouldn't just allow SET STORAGE on foreign tables. It's probably
not going to have any effect, but so what? And again, if we did ever
find a use for that, we'd have a compatibility problem if inherited SET
STORAGE has a pre-existing behavior that it skips foreign children.
In the same vein, I'm planning to take out the existing prohibition on
marking CHECK constraints on foreign tables NOT VALID. That likewise
creates a corner case for inheritance trees for no obviously good reason.
It was reasonable to be conservative about whether to allow that so long
as there were no side-effects; but putting warts into the behavior of
inheritance trees to preserve the prohibition is not a good outcome.
regards, tom lane