Re: Self-join elimination discards differing row lock wait policies

I wrote:
> 3. By the same argument, my complaint above about two RTEs with
> and without rowmarks is faulty. As long as we keep the rowmark,
> dropping the RTE without rowmark is not problematic, because
> each of the cases I just listed works the same if the second
> RTE applies no row lock at all.

I realized that this argument is still faulty, because an RTE with a
locking-type rowmark potentially represents a different set of row
values than an RTE that has no mark or a ROW_MARK_REFERENCE mark
(i.e., fully-updated versus current-as-of-the-query-snapshot).
So we could potentially merge RTEs that have locking rowmarks of
different strengths, and we could potentially merge non-locking RTEs,
but we can't merge across those groups.

The existing test for same-markType keeps us from merging a
ROW_MARK_REFERENCE mark with a locking mark, but it's stronger
than it has to be. And there is a bug, which is that the code is
willing to merge an RTE with locking mark with an RTE that has no
mark. But it turns out that that bug is only latent, because
preprocess_rowmarks has previously seen to it that all or none of the
query's rels have PlanRowMarks. (Except for an UPDATE/DELETE target
rel, but analyzejoins.c rejects SJE with the target rel anyway.)

So I still don't see a reachable bug here, but there's dead code
(the bit about handling an rmark without kmark), and the
commentary omits even more than I thought before.

I experimented with writing logic that would allow merging locks of
different strengths, but I'm not really convinced that it's worth the
trouble.

regards, tom lane