From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Michael Paquier <michael@paquier.xyz>, exclusion@gmail.com,
        pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible
 fields that leads to a server crash
In-reply-to: <20230221233349.lj3btvtyqog5jzxd@awork3.anarazel.de>
References: <17800-ff90866b3906c964@postgresql.org>
 <Y/P49Yov2m+VzfFf@paquier.xyz>
 <20230221193352.mvzpuvoujfmckvr3@awork3.anarazel.de>
 <3990862.1677010571@sss.pgh.pa.us>
 <20230221204201.idad3kjv3ue7gb6s@awork3.anarazel.de>
 <3995669.1677012915@sss.pgh.pa.us>
 <20230221221602.42n3pheoafjsmouj@awork3.anarazel.de>
 <4060951.1677018870@sss.pgh.pa.us>
 <20230221233349.lj3btvtyqog5jzxd@awork3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Tue, 21 Feb 2023 15:33:49 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4111537.1677024007.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 21 Feb 2023 19:00:07 -0500
Message-ID: <4111538.1677024007@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/4111538.1677024007%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> Perhaps we should deal with this by generating a distinct type of expres=
sion
> step, that looks up information about the param in a different place? No=
thing
> forces us to have the expression step look into
> 	prm =3D &(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 par=
ams
> from? I don't think we currently have a good way to figure that out duri=
ng
> 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