Re: Attribute of type record has wrong type error with MERGE ... WHEN NOT MATCHED BY SOURCE THEN DELETE

Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> Unfortunately, it looks like this bug pre-dates MERGE WHEN NOT MATCHED
> BY SOURCE, and even MERGE itself. All that's needed to trigger it is a
> query that causes 2 whole-row Vars to be added, one before and one
> after view expansion. That can be made to happen via the rowmarking
> mechanism in all supported branches as follows:

Ugh, right. So I withdraw my objection to fixing this in
makeWholeRowVar: all of the post-rewrite calls have need for this
behavior. However, the proposed code change is wrong in detail.
The existing places that are checking for this situation are doing
tests like
(rte->rtekind == RTE_SUBQUERY && OidIsValid(rte->relid)))
I don't believe that checking relkind instead is an improvement.

> Reading the commit message for 47bb9db7599 suggests that maybe it
> would be OK to further back-patch the changes to ApplyRetrieveRule()
> to retain relkind and relid on subquery RTEs for this purpose. That
> wouldn't affect stored rules, but I haven't looked to see what else it
> might affect.

Yeah, I think we can likely get away with that. We cannot back-patch
the changes that added relid to the outfuncs/readfuncs representation,
which means that the RTE's relid won't propagate to parallel workers,
but I don't see why they'd need it. We only need that info to get
as far as planning. I've not tried though.

Draft HEAD patch attached.

regards, tom lane