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: <20230221221602.42n3pheoafjsmouj@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>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Tue, 21 Feb 2023 14:16:02 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4060950.1677018870.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 21 Feb 2023 17:34:30 -0500
Message-ID: <4060951.1677018870@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/4060951.1677018870%40sss.pgh.pa.us>
Precedence: bulk

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 separ=
ate
>> ParamKind, that would have a less-than-query-wide scope.  We might be a=
ble
>> 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 ExprCont=
ext
> that'd point to such a separate array. That'd allow you to choose the th=
e
> separate array on a per-expression-evaluation basis (not even per ExprSt=
ate).
> We already have multiple ExprContexts in some nodes, so this wouldn't br=
eak
> 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