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 |
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 |