Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash

Andres Freund <andres@anarazel.de> writes:
> On 2023-02-21 15:55:15 -0500, Tom Lane wrote:
>> What I'm wondering about is adding a separate array, and likely a separate
>> ParamKind, that would have a less-than-query-wide scope.  We might be able
>> to get away with having that be plan-node-wide, but making it local to the
>> specific compiled expression feels safer and easier to reason about.

> What I was trying to suggest is that you could have a dedicated ExprContext
> that'd point to such a separate array. That'd allow you to choose the the
> separate array on a per-expression-evaluation basis (not even per ExprState).
> We already have multiple ExprContexts in some nodes, so this wouldn't break
> new ground.

I'd really like to *not* need the surrounding plan node to know about
this.  The tlist push-down behavior shown upthread would result in
that requirement propagating to just about every plan node type,
certainly every one that allows projection.

If we're certain that we'll only need this for MULTIEXPR_SUBLINK and
thus only in tlists, we could conceivably put the support into
ExecProject and friends rather than directly in the ExprState
infrastructure.  But that feels like a rather strange compromise,
and it'd foreclose using the concept for other short-lifespan
Param-like nodes.

Another idea I'm toying with is that the expression compiler could
allocate some space when it sees a MULTIEXPR_SUBLINK, and then
connect up the multiexec Params to that.

            regards, tom lane