(2019/02/21 0:14), Tom Lane wrote:
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.
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
