(2019/02/21 0:14), Tom Lane wrote:
> Etsuro Fujita<fujita.etsuro@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.
Seems reasonable. I guess that that can address not only the issue [1]
but our restriction on FDW row locking that APIs for that currently only
allow TID for row identity, in a uniform way.
> 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.
OK, thanks for the explanation!
Best regards,
Etsuro Fujita