Re: Another way to fix inherited UPDATE/DELETE

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