Fix for recursive plpython triggers

Started by Tom Lanealmost 2 years ago3 messageshackers
Jump to latest
#1Tom Lane
tgl@sss.pgh.pa.us

This fixes bug #18456 [1]/messages/by-id/18456-82d3d70134aefd28@postgresql.org. Since we're in back-branch release freeze,
I'll just park it for the moment. But I think we should shove it in
once the freeze lifts so it's in 17beta1.

regards, tom lane

[1]: /messages/by-id/18456-82d3d70134aefd28@postgresql.org

Attachments:

v1-save-TD-in-recursive-plpython-triggers.patchtext/x-diff; charset=us-ascii; name=v1-save-TD-in-recursive-plpython-triggers.patchDownload+80-3
#2Andreas Karlsson
andreas.karlsson@percona.com
In reply to: Tom Lane (#1)
Re: Fix for recursive plpython triggers

On 5/4/24 10:16 PM, Tom Lane wrote:

This fixes bug #18456 [1]. Since we're in back-branch release freeze,
I'll just park it for the moment. But I think we should shove it in
once the freeze lifts so it's in 17beta1.

There is a similar issue with the return type (at least if it is a
generic record) in the code but it is hard to trigger with sane code so
I don't know if it is worth fixing but this and the bug Jacques found
shows the downsides of the hacky fix for recursion that we have in plpython.

I found this issue while reading the code, so am very unclear if there
is any sane code which could trigger it.

In the example below the recursive call to f('int') changes the return
type of the f('text') call causing it to fail.

# CREATE OR REPLACE FUNCTION f(t text) RETURNS record LANGUAGE
plpython3u AS $$
if t == "text":
plpy.execute("SELECT * FROM f('int') AS (a int)");
return { "a": "x" }
elif t == "int":
return { "a": 1 }
$$;
CREATE FUNCTION

# SELECT * FROM f('text') AS (a text);
ERROR: invalid input syntax for type integer: "x"
CONTEXT: while creating return value
PL/Python function "f"

Andreas

#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andreas Karlsson (#2)
Re: Fix for recursive plpython triggers

Andreas Karlsson <andreas@proxel.se> writes:

I found this issue while reading the code, so am very unclear if there
is any sane code which could trigger it.

In the example below the recursive call to f('int') changes the return
type of the f('text') call causing it to fail.

# CREATE OR REPLACE FUNCTION f(t text) RETURNS record LANGUAGE
plpython3u AS $$
if t == "text":
plpy.execute("SELECT * FROM f('int') AS (a int)");
return { "a": "x" }
elif t == "int":
return { "a": 1 }
$$;
CREATE FUNCTION

# SELECT * FROM f('text') AS (a text);
ERROR: invalid input syntax for type integer: "x"
CONTEXT: while creating return value
PL/Python function "f"

Oh, nice one. I think we can fix this trivially though: the problem
is that RECORD return-type setup was stuck into PLy_function_build_args,
where it has no particular business being in the first place, rather
than being done at the point of use. We can just move the code.

regards, tom lane

Attachments:

fix-plpython-record-result-setup.patchtext/x-diff; charset=us-ascii; name=fix-plpython-record-result-setup.patchDownload+17-16