Re: inherit support for foreign tables

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, noah(at)leadboat(dot)com, shigeru(dot)hanada(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: inherit support for foreign tables
Date: 2015-03-20 18:50:19
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Gierth 2015-03-20 18:51:25 Re: configure can't detect proper pthread flags
Previous Message Robert Haas 2015-03-20 18:07:55 Re: assessing parallel-safety