Horton

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

Pavel Stehule <pavel.stehule@gmail.com>

View thread
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>, Jim Jones <jim.jones@uni-muenster.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-09-21T15:07:50Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Improve detection of implicitly-temporary views.

  2. Issue a NOTICE if a created function depends on any temp objects.

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
>