Re: Add notification on BEGIN ATOMIC SQL functions using temp relations

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Add notification on BEGIN ATOMIC SQL functions using temp relations
Date: 2025-09-21 17:14:36
Message-ID: CAFj8pRAEf7ZxzPbOgnmGX6xiEh1jHs8NctQgkc0eBF1sLPD83Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

ne 21. 9. 2025 v 18:42 odesílatel Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>
napsal:

>
>
> On 9/21/25 17:37, Jim Jones wrote:
> >
> >
> > On 9/21/25 16:59, Tom Lane wrote:
> >> There's a larger issue here though: a function such as Jim shows
> >> is a normal function, probably stored in the public schema, and
> >> by default other sessions will be able to call it. But it will
> >> certainly not work as desired for them, since they can't access
> >> the creating session's temp tables. It would likely bollix
> >> a concurrent pg_dump too. I wonder if we'd be better off to
> >> forbid creation of such a function altogether.
> >
> > That's indeed a much larger problem. Calling it from a session silently
> > delivers a "wrong" result --- I was expecting an error.
> >
> > == Session 1 ==
> >
> > $ /usr/local/postgres-dev/bin/psql postgres
> > psql (19devel)
> > Type "help" for help.
> >
> > postgres=#
> > postgres=# CREATE TEMPORARY TABLE tmp AS SELECT 42 AS val;
> > SELECT 1
> > postgres=# CREATE FUNCTION f()
> > RETURNS int LANGUAGE sql
> > BEGIN ATOMIC;
> > SELECT val FROM tmp;
> > END;
> > CREATE FUNCTION
> > postgres=# SELECT f();
> > f
> > ----
> > 42
> > (1 row)
> >
> > == Session 2 (concurrent) ==
> >
> > $ /usr/local/postgres-dev/bin/psql postgres
> > psql (19devel)
> > Type "help" for help.
> >
> > postgres=# SELECT f();
> > f
> > ---
> >
> > (1 row)
> >
> >
> > In that light, forbidding creation of functions that depend on temporary
> > objects might be the safer and more consistent approach.
> >
> As Tom pointed out, pg_dump produces strange output in this case: it
> shows a reference to a temporary table that shouldn’t even be visible:
>
> ...
>
> --
> -- Name: f(); Type: FUNCTION; Schema: public; Owner: jim
> --
>
> CREATE FUNCTION public.f() RETURNS integer
> LANGUAGE sql
> BEGIN ATOMIC
> SELECT tmp.val
> FROM pg_temp_3.tmp;
> END;
>
> ...
>
> This seems to confirm that allowing such functions leads to more than
> just user confusion --- it creates broken dump/restore behaviour.
>
> Given that, I agree forbidding functions from referencing temporary
> relations is probably the right fix. If there's consensus, I can rework
> my PoC in that direction.
>

only when the function is not created in pg_temp schema - I think

Pavel

>
> Best regards, Jim
>
>
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-09-21 17:32:59 We broke the defense against accessing other sessions' temp tables
Previous Message Jim Jones 2025-09-21 16:42:28 Re: Add notification on BEGIN ATOMIC SQL functions using temp relations