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
18 matches
Mail list logo
