Re: AssertArg failure in src/backend/executor/functions.c:check_sql_fn_retval()

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: AssertArg failure in src/backend/executor/functions.c:check_sql_fn_retval()
Дата
Msg-id 4781.1459089603@sss.pgh.pa.us
обсуждение исходный текст
Ответ на AssertArg failure in src/backend/executor/functions.c:check_sql_fn_retval()  (Piotr Stefaniak <postgres@piotr-stefaniak.me>)
Ответы Re: AssertArg failure in src/backend/executor/functions.c:check_sql_fn_retval()  (Piotr Stefaniak <postgres@piotr-stefaniak.me>)
Список pgsql-hackers
Piotr Stefaniak <postgres@piotr-stefaniak.me> writes:
> using sqlsmith I found a way to induce an AssertArg failure in 
> src/backend/executor/functions.c:check_sql_fn_retval() for 
> assert-enabled builds. It boils down to creating a function and calling 
> it like this:

> CREATE FUNCTION bad_argument_assert(anyarray, integer) RETURNS anyarray 
> LANGUAGE sql AS $$select $1$$;
> SELECT bad_argument_assert(CAST(NULL AS ANYARRAY), 0);

Hm.  I would argue that it should have rejected CAST(NULL AS ANYARRAY).
That's a pseudotype and so there should never be an actual value of that
type, not even a null value.

The Assert is positing that the type resolution system took care of
mapping some actual array type into ANYARRAY, but here the parser
didn't notice that it had anything to resolve, because it had an
exact match of input data type for the function.
        regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Alter or rename enum value
Следующее
От: Andres Freund
Дата:
Сообщение: Re: GinPageIs* don't actually return a boolean