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

Andres Freund <andres(at)anarazel(dot)de> writes:
> Perhaps we should deal with this by generating a distinct type of expression
> step, that looks up information about the param in a different place? Nothing
> forces us to have the expression step look into
> prm = &(econtext->ecxt_param_exec_vals[op->d.param.paramid]);

Right, where I was going was to have a distinct EEOP type that finds
the ParamExecData in some other way. The main question is where to keep
that not-so-global ParamExecData.

>> 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.

> Where are you thinking of getting the information for connecting the params
> from? I don't think we currently have a good way to figure that out during
> evaluation time, right?

It would have to look something like the forward-jump fixup logic,
that is keep track of unfinished Param-referencing steps and go back
to fill them in when it finds the driving MULTIEXPR_SUBLINK and allocates
some space to hold the output of that. A lot of details still to be
filled in there, but it doesn't seem very different from stuff we're
already doing.

regards, tom lane