Re: Killing off removed rels properly

I wrote:
>> It looks like we're somehow triggering the elide-a-left-join code
>> when we shouldn't?

So the reason why we see this with a partitioned target table and not
with a regular target table reduces to this bit in preprocess_targetlist:

    /*
     * For non-inherited UPDATE/DELETE/MERGE, register any junk column(s)
     * needed to allow the executor to identify the rows to be updated or
     * deleted.  In the inheritance case, we do nothing now, leaving this to
     * be dealt with when expand_inherited_rtentry() makes the leaf target
     * relations.  (But there might not be any leaf target relations, in which
     * case we must do this in distribute_row_identity_vars().)
     */
    if ((command_type == CMD_UPDATE || command_type == CMD_DELETE ||
         command_type == CMD_MERGE) &&
        !target_rte->inh)
    {
        /* row-identity logic expects to add stuff to processed_tlist */
        root->processed_tlist = tlist;
        add_row_identity_columns(root, result_relation,
                                 target_rte, target_relation);
        tlist = root->processed_tlist;
    }

This happens before join removal, so that we see use of the row identity
columns of a regular table as a reason not to do join removal.  But
expand_inherited_rtentry will happen after that, too late to stop join
removal.

I think the best fix is just to teach join removal that it mustn't
remove the result relation, as attached (needs a regression test).

I'm a little inclined to back-patch this, even though I think it's
probably unreachable in v15.  It's a cheap enough safety measure,
and at the very least it will save a few cycles deciding that we
can't remove the target table of a MERGE.

			regards, tom lane