Re: Fix for recursive plpython triggers

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andreas Karlsson <andreas(at)proxel(dot)se>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Fix for recursive plpython triggers
Date: 2024-05-08 15:51:17
Message-ID: 552755.1715183477@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andreas Karlsson <andreas(at)proxel(dot)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

Attachment Content-Type Size
fix-plpython-record-result-setup.patch text/x-diff 1.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jonathan S. Katz 2024-05-08 16:17:13 Re: 2024-05-09 release announcement draft
Previous Message Andrey M. Borodin 2024-05-08 15:37:11 Re: UUID v7