Re: proposal: schema variables - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal: schema variables
Date
Msg-id CAFj8pRDBr516DeKjQ4kRg8XZeScsTBFLZMY3dpN8kpVM2TKv1A@mail.gmail.com
Whole thread
In response to Re: proposal: schema variables  (Haritabh Gupta <haritabh1992@gmail.com>)
List pgsql-hackers
Hi

st 4. 3. 2026 v 11:03 odesílatel Haritabh Gupta <haritabh1992@gmail.com> 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 = 42;

    BEGIN;
    SAVEPOINT s1;
    LET y = 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

pgsql-hackers by date:

Previous
From: Maciek Sakrejda
Date:
Subject: Re: V18 change on EXPLAIN ANALYZE
Next
From: Jacob Champion
Date:
Subject: Re: Improve OAuth discovery logging