Re: AssertArg failure in src/backend/executor/functions.c:check_sql_fn_retval() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: AssertArg failure in src/backend/executor/functions.c:check_sql_fn_retval()
Date
Msg-id 4781.1459089603@sss.pgh.pa.us
Whole thread Raw
In response to AssertArg failure in src/backend/executor/functions.c:check_sql_fn_retval()  (Piotr Stefaniak <postgres@piotr-stefaniak.me>)
Responses Re: AssertArg failure in src/backend/executor/functions.c:check_sql_fn_retval()
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Alter or rename enum value
Next
From: Andres Freund
Date:
Subject: Re: GinPageIs* don't actually return a boolean