Re: BUG #17823: Generated columns not always updated correctly

I wrote:
> Yeah. Looking into nodeModifyTable.c, we miss re-doing
> ExecComputeStoredGenerated when looping back after an EPQ update
> (which is what this case is). I see that we also fail to redo that
> after a cross-partition move, which is a bug since 8bf6ec3ba.
> The attached seems to be enough to fix it, but I want to also devise
> an isolation test for these cases ...

Building a test case for cross-partition updates showed that there's
a second problem: when we convert an UPDATE into an INSERT on another
partition, we really need to compute all the other partition's
GENERATED columns (as a real INSERT would); but we might only compute
some of them, if we'd already initialized the target partition's
ri_GeneratedExprs data as for an UPDATE.

AFAICS the only true fix for this is to keep separate ri_GeneratedExprs
data for INSERT and UPDATE cases. Most of the time we'd only compute
one set for any given target partition; but a given partition could
receive both local UPDATEs and cross-partition INSERTs in the same
UPDATE command, so it can happen that we need both.

Hence the attached. One improvement we can make is to drop the
early call of ExecInitStoredGenerated in ExecInitModifyTable, and
calculate this stuff only upon-demand. The claim that we have to
do it to pre-fill ri_extraUpdatedCols is wrong given that
ExecGetExtraUpdatedCols now knows to call ExecInitStoredGenerated.

I'm not sure how much of this needs to be back-patched. I think that
before 8bf6ec3ba, it might not matter if a cross-partition INSERT misses
doing some of the target partition's GENERATED expressions, since they
should match those of the source partition which we'd have already
computed correctly in the to-be-inserted tuple.

regards, tom lane