Etsuro Fujita <fujita.ets...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers