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

From Tom Lane
Subject Re: Add notification on BEGIN ATOMIC SQL functions using temp relations
Date
Msg-id 2667619.1763836641@sss.pgh.pa.us
Whole thread Raw
In response to Re: Add notification on BEGIN ATOMIC SQL functions using temp relations  (Jim Jones <jim.jones@uni-muenster.de>)
Responses Re: Add notification on BEGIN ATOMIC SQL functions using temp relations
List pgsql-hackers
Jim Jones <jim.jones@uni-muenster.de> writes:
> On 22/11/2025 00:46, Tom Lane wrote:
>> Although I've left the patch throwing an error (with new wording)
>> for now, I wonder if it'd be better to reduce the error to a NOTICE,
>> perhaps worded like "function f will be effectively temporary due to
>> its dependence on <object>".

> I briefly considered this option, but since there is no equivalent to
> temporary views, I didn't explore it much. I can see the appeal of
> reducing it to a NOTICE, so that we 1) don't break existing scripts and
> 2) still allow users to create “temporary functions.” The argument
> against only showing a NOTICE was that it could create invalid output
> for a concurrent pg_dump ...

Yeah.  That does not bother me much: the restore will still succeed
(unless you try to use --single-transaction) with just the function
missing, which is the same state of affairs as if you'd dumped after
the creating session exited.  There are plenty of other ways to
create dumps that will cause a similar level of annoyance.

After sleeping on it, I'm inclined to word the notice like

NOTICE:  function "f" will be effectively temporary
DETAIL:  It depends on temporary <object descriptor>.

This is pretty close to the way that the corresponding notice
for views is worded.  And I'm thinking seriously about a follow-up
patch that adds similar DETAIL for the view case, after jacking up
the very hoary code that produces that notice for views and driving
this infrastructure underneath it.  (That's why I changed the code
to separate the error text from the infrastructure.)

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: another autovacuum scheduling thread
Next
From: Robert Haas
Date:
Subject: Re: [PATCH] Allow complex data for GUC extra.