Jim Jones writes:
> While playing with v9 I realised that this issue also affects
> non-temporary tables when they use temporary types (in pg_temp)::
Right. Really the dependency-on-temp-type scenario affects a ton of
object types: aggregates, casts, domains, operators, you name it.
> The colum
On 23/11/2025 21:20, Tom Lane wrote:
> Pushed with some more editing; for instance there were a bunch
> of comments still oriented toward throwing an error. I also
> still thought the tests were pretty duplicative.
Thanks!
> One note is that I took out
>
> +(errcode(ERRCODE_F
Jim Jones writes:
> v8 attached.
Pushed with some more editing; for instance there were a bunch
of comments still oriented toward throwing an error. I also
still thought the tests were pretty duplicative.
One note is that I took out
+(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
an
On 22/11/2025 19:37, Tom Lane wrote:
> After sleeping on it, I'm inclined to word the notice like
>
> NOTICE: function "f" will be effectively temporary
> DETAIL: It depends on temporary .
I changed the error level to NOTICE:
postgres=# CREATE TEMPORARY TABLE temp_table AS SELECT 1 AS val;
Tom Lane wrote:
>if a temp table is used to
> define an old-style function's argument or result type, eg
> create function get_mytable() returns setof mytable as ...
> This is problematic because the function will go away when mytable
> does, no matter how its body is expressed.
I briefly
Jim Jones 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 ".
> I
Tom Lane wrote:
> No, that's not part of the proposal. The one case in which we'd
> complain (at an error level TBD) is if a temp table is used to
> define an old-style function's argument or result type
Thank you, I see I was being an idiot.
Bernice Southey writes:
> Yikes. Can I get in early on the push-back? I think what you're saying
> is you want to stop old-style SQL functions from using temp tables
> that exist outside of them?
No, that's not part of the proposal. The one case in which we'd
complain (at an error level TBD) is
On Sat, Nov 22, 2025 at 4:01 PM Tom Lane wrote:
> The big change is that it makes zero sense to me to apply this
> restriction only to new-style SQL functions. If it's bad for an
> allegedly non-temporary function to disappear at session exit,
> surely it's not less bad just because it's old-styl
On 22/11/2025 00:46, Tom Lane wrote:
> Jim Jones writes:
>> PFA v6 with these changes.
>
> I went through this and made one big change and some cosmetic ones.
>
> The big change is that it makes zero sense to me to apply this
> restriction only to new-style SQL functions. If it's bad for an
I 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 ".
This is, of course, pretty much what you suggested origi
Jim Jones writes:
> PFA v6 with these changes.
I went through this and made one big change and some cosmetic ones.
The big change is that it makes zero sense to me to apply this
restriction only to new-style SQL functions. If it's bad for an
allegedly non-temporary function to disappear at sess
On 04/11/2025 21:41, Tom Lane wrote:
> 0001 is mostly what I had in mind, except that I do not think
> collectDependenciesFromExpr should perform
> eliminate_duplicate_dependencies; it should be explicitly documented
> that the caller should do that before recording the dependencies.
> This appro
Jim Jones writes:
> Oops... wrong files. Sorry.
> PFA the correct version.
A few thoughts:
0001 is mostly what I had in mind, except that I do not think
collectDependenciesFromExpr should perform
eliminate_duplicate_dependencies; it should be explicitly documented
that the caller should do that
Jim Jones writes:
> [ v3-0001-Disallow-ATOMIC-functions-depending-on-temp-relat.patch ]
Got around to reading the patch finally. I don't like anything
about this implementation. It introduces yet another place that
(thinks it) knows how to find all the dependencies in a query
tree, requiring ye
rebased
JimFrom 0ace0c986371a3bc13b4e0e7128b06e751382aa6 Mon Sep 17 00:00:00 2001
From: Jim Jones
Date: Wed, 8 Oct 2025 21:12:32 +0200
Subject: [PATCH v3] Disallow ATOMIC functions depending on temp relations
When a SQL function is defined with a BEGIN ATOMIC block and
references a temporary re
On 10/13/25 17:16, Jim Jones wrote:
> PFA a first attempt to address your points.
Oops... wrong files. Sorry.
PFA the correct version.
JimFrom 5e538c3cab1db93ffdff821007b900d1ffd60e39 Mon Sep 17 00:00:00 2001
From: Jim Jones
Date: Mon, 13 Oct 2025 13:48:08 +0200
Subject: [PATCH v5 1/2] Refacto
Hi Tom,
Thanks for the review and thorough feedback.
On 10/8/25 22:35, Tom Lane wrote:
> I think the right way to make this work is to look through the
> array of ObjectAddresses that ProcedureCreate builds to store
> into pg_depend, because that is by definition the authoritative
> info about wh
On 9/21/25 19:34, Tom Lane wrote:
> Jim Jones writes:
>> That's indeed a much larger problem. Calling it from a session silently
>> delivers a "wrong" result --- I was expecting an error.
>
> Yeah, me too. See
>
> https://www.postgresql.org/message-id/2736425.1758475979%40sss.pgh.pa.us
>
Th
Jim Jones writes:
> That's indeed a much larger problem. Calling it from a session silently
> delivers a "wrong" result --- I was expecting an error.
Yeah, me too. See
https://www.postgresql.org/message-id/2736425.1758475979%40sss.pgh.pa.us
regards, tom lane
ne 21. 9. 2025 v 18:42 odesílatel Jim Jones
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 oth
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
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 acce
Hi Pavel
On 9/21/25 14:33, Pavel Stehule wrote:
> i understand your motivation, but with this warning temp tables cannot
> be used in SQL function due log overhead.
My intention was not to warn on every function call. The WARNING is only
emitted once at CREATE FUNCTION time, similar to how CREATE
ne 21. 9. 2025 v 16:59 odesílatel Tom Lane napsal:
> "David G. Johnston" 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 tempor
"David G. Johnston" 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.f
On 21/09/2025 13:49, Jim Jones wrote:
WARNING: function defined with BEGIN ATOMIC depends on temporary
relation "tmp"
DETAIL: the function will be dropped automatically at session end.
CREATE FUNCTION
In addition to what others have said, this DETAIL line needs to be
contextual. The temp
On Sunday, September 21, 2025, Jim Jones wrote:
> Hi Pavel
>
> On 9/21/25 14:33, Pavel Stehule wrote:
> > i understand your motivation, but with this warning temp tables cannot
> > be used in SQL function due log overhead.
>
> My intention was not to warn on every function call. The WARNING is on
Hi
ne 21. 9. 2025 v 13:49 odesílatel Jim Jones
napsal:
> Hi,
>
> While reviewing a patch I noticed that SQL functions defined with BEGIN
> ATOMIC can reference temporary relations, and such functions are
> (rightfully) dropped at session end --- but without any notification to
> the user:
>
> $
Hi,
While reviewing a patch I noticed that SQL functions defined with BEGIN
ATOMIC can reference temporary relations, and such functions are
(rightfully) dropped at session end --- but without any notification to
the user:
$ /usr/local/postgres-dev/bin/psql postgres
psql (19devel)
Type "help" for
30 matches
Mail list logo
