Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> writes: > (2019/02/20 6:48), Tom Lane wrote: >> In the case of a standard inheritance or partition tree, this seems to >> go through really easily, since all the children could share the same >> returned CTID column (I guess you'd also need a TABLEOID column so you >> could figure out which table to direct the update back into). It gets >> a bit harder if the tree contains some foreign tables, because they might >> have different concepts of row identity, but I'd think in most cases you >> could still combine those into a small number of output columns.
> If this is the direction we go in, we should work on the row ID issue > [1] before this? Certainly, the more foreign tables can use a standardized concept of row identity, the better this would work. What I'm loosely envisioning is that we have one junk row-identity column for each distinct row-identity datatype needed --- so, for instance, all ordinary tables could share a TID column. Different FDWs might need different things, though one would hope for no more than one datatype per FDW-type involved in the inheritance tree. Where things could break down is if we have a lot of tables that need a whole-row-variable for row identity, and they're all different rowtypes --- eventually we'd run out of available columns. So we'd definitely wish to encourage FDWs to have some more efficient row-identity scheme than that one. I don't see that as being something that constrains those two projects to be done in a particular order; it'd just be a nice-to-have improvement. regards, tom lane