segfault in 9.5alpha - plpgsql function, implicit cast and IMMUTABLE cast function
От | Geoff Winkless |
---|---|
Тема | segfault in 9.5alpha - plpgsql function, implicit cast and IMMUTABLE cast function |
Дата | |
Msg-id | CAEzk6fdVan-rUr5Le2BfNfKncniMdyk4vyVZYnKX_TBJu34Zdw@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: segfault in 9.5alpha - plpgsql function, implicit cast
and IMMUTABLE cast function
Re: segfault in 9.5alpha - plpgsql function, implicit cast and IMMUTABLE cast function |
Список | pgsql-hackers |
SELECT $1::text::date
$$;
DROP CAST IF EXISTS (integer AS date);
CREATE CAST (integer AS date) WITH FUNCTION to_date(integer) AS IMPLICIT;
CREATE OR REPLACE FUNCTION newcrash(INTEGER) returns DATE LANGUAGE plpgsql AS $$ BEGIN
RETURN $1;
END$$;
SELECT newcrash(20150202);
SELECT newcrash(20150203);
============ cut ===============
It doesn't crash the first time, but does consistently crash the second. Given that if I remove IMMUTABLE from the function definition it doesn't fail, it implies that there's a problem with the mechanism used to cache function results - although the fact that the second function call doesn't have to be the same value does suggest it's a problem with the code that searches that result cache, rather than the section that retrieves it.
I tried cutting out the implicit CAST altogether and doing
RETURN to_date($1);
but this doesn't fail, which implies also that it's something related to the implicit cast.
If I DECLARE a local DATE variable and SELECT INTO that (rather than just using RETURN $1), it crashes at that point too.
Geoff
В списке pgsql-hackers по дате отправления: