Re: Fix for recursive plpython triggers

Поиск
Список
Период
Сортировка
От Andreas Karlsson
Тема Re: Fix for recursive plpython triggers
Дата
Msg-id 1651a46d-3c15-4028-a8c1-d74937b54e19@proxel.se
обсуждение исходный текст
Ответ на Fix for recursive plpython triggers  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Fix for recursive plpython triggers
Список pgsql-hackers
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [PATCH] json_lex_string: don't overread on bad UTF8
Следующее
От: Shubham Khanna
Дата:
Сообщение: Re: Pgoutput not capturing the generated columns