MIME-Version: 1.0
References: 
 <CAFj8pRDY+m9OOxfO10R7J0PAkCCauM-TweaTrdsrsLGMb1VbEQ@mail.gmail.com>
 <CAFj8pRDLL-srue=m+je26vFrMzwETWwOfsEVNwr7=_KhuWA1bQ@mail.gmail.com>
 <177261853144.1094601.11795093672679754617.pgcf@coridan.postgresql.org>
In-Reply-To: 
 <177261853144.1094601.11795093672679754617.pgcf@coridan.postgresql.org>
From: Pavel Stehule <pavel.stehule@gmail.com>
Date: Wed, 4 Mar 2026 20:15:26 +0100
Message-ID: 
 <CAFj8pRDBr516DeKjQ4kRg8XZeScsTBFLZMY3dpN8kpVM2TKv1A@mail.gmail.com>
Subject: Re: proposal: schema variables
To: Haritabh Gupta <haritabh1992@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000d88932064c37a6d1"
Archived-At: 
 <https://www.postgresql.org/message-id/CAFj8pRDBr516DeKjQ4kRg8XZeScsTBFLZMY3dpN8kpVM2TKv1A%40mail.gmail.com>
Precedence: bulk

--000000000000d88932064c37a6d1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi

st 4. 3. 2026 v 11:03 odes=C3=ADlatel Haritabh Gupta <haritabh1992@gmail.co=
m>
napsal:

> Hi,
>
> While reviewing I came across this behaviour and wanted to
> check whether it's intended:
>
>     CREATE TEMP VARIABLE y AS int;
>     LET y =3D 42;
>
>     BEGIN;
>     SAVEPOINT s1;
>     LET y =3D generate_series(1,2);  -- ERROR: too many rows
>     ROLLBACK TO s1;
>     SELECT VARIABLE(y);            -- returns 1, not 42
>
> It looks like svariableReceiveSlot writes the first row to the
> variable (pfree'ing the old datum) before the second row triggers the
> error, so the old value is lost even though LET failed.
>
> I understand variable values are intentionally non-transactional, but
> is it expected that a failed LET has this side effect?
>

Yes, it does like you describe it. It is the most simple solution, because
I don't need any extra buffer, and I can assign the value immediately when
I have the value.

I think I can postpone an assignment to svariableShutdownReceiver with a
few more lines to get the behaviour that you expect.

Regards

Pavel


> ---
> Haritabh Gupta
> Supabase

--000000000000d88932064c37a6d1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div>Hi</div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr" class=3D"gmail_attr">st 4. 3. 2026 v=C2=A011:03 odes=C3=
=ADlatel Haritabh Gupta &lt;<a href=3D"mailto:haritabh1992@gmail.com" targe=
t=3D"_blank">haritabh1992@gmail.com</a>&gt; napsal:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
While reviewing I came across this behaviour and wanted to<br>
check whether it&#39;s intended:<br>
<br>
=C2=A0 =C2=A0 CREATE TEMP VARIABLE y AS int;<br>
=C2=A0 =C2=A0 LET y =3D 42;<br>
<br>
=C2=A0 =C2=A0 BEGIN;<br>
=C2=A0 =C2=A0 SAVEPOINT s1;<br>
=C2=A0 =C2=A0 LET y =3D generate_series(1,2);=C2=A0 -- ERROR: too many rows=
<br>
=C2=A0 =C2=A0 ROLLBACK TO s1;<br>
=C2=A0 =C2=A0 SELECT VARIABLE(y);=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
-- returns 1, not 42<br>
<br>
It looks like svariableReceiveSlot writes the first row to the<br>
variable (pfree&#39;ing the old datum) before the second row triggers the<b=
r>
error, so the old value is lost even though LET failed.<br>
<br>
I understand variable values are intentionally non-transactional, but<br>
is it expected that a failed LET has this side effect? <br></blockquote><di=
v><br></div><div>Yes, it does like you describe it. It is the most simple s=
olution, because I don&#39;t need any extra buffer, and I can assign the va=
lue immediately when I have the value.</div><div><br></div><div>I think I c=
an postpone an assignment to=C2=A0svariableShutdownReceiver with a few more=
 lines to get the behaviour that you expect.</div><div><br></div><div>Regar=
ds</div><div><br></div><div>Pavel</div><div><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">
<br>
---<br>
Haritabh Gupta<br>
Supabase</blockquote></div></div>
</div>

--000000000000d88932064c37a6d1--