Re: Add notification on BEGIN ATOMIC SQL functions using temp relations - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Add notification on BEGIN ATOMIC SQL functions using temp relations
Date
Msg-id CAFj8pRBGUXdwuLg4edqDWVe2NTRUcBctFk05YAZ4djR3YRbG=A@mail.gmail.com
Whole thread Raw
In response to Re: Add notification on BEGIN ATOMIC SQL functions using temp relations  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers


ne 21. 9. 2025 v 16:59 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> I’m surprised that this is how the system works and I agree that either we
> should add this notice or remove the one for create view.  Even more
> because there is no syntax for directly creating a temporary function -

It is possible to do

CREATE FUNCTION pg_temp.foo() ...

However, then it's not in your search path and you have to write
"pg_temp.foo" to call it, so this is far from transparent.

The fact that you can't call a temporary function without explicit
schema qualification is a security decision that is very unlikely
to get relaxed.  But because of that, temp functions aren't really
first-class objects, and so I wouldn't be in favor of inventing
CREATE TEMP FUNCTION.

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.

+1

Pavel
 

                        regards, tom lane

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Add notification on BEGIN ATOMIC SQL functions using temp relations
Next
From: Jim Jones
Date:
Subject: Re: Add notification on BEGIN ATOMIC SQL functions using temp relations