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

[Piotr Stefaniak]

On 2016-03-27 16:40, Tom Lane wrote:

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.


I'm a little confused about what you mean here. I thought reject was 
exactly what's happening; normally you'd get "ERROR:  return type 
anyarray is not supported for SQL functions".


If you mean specifically to forbid CAST(NULL AS ANYARRAY) in general 
then I'd like to point out that there are columns of type anyarray, at 
least pg_catalog.pg_statistic.stavalues1 is, so the cast is not the only 
way to trigger this.




--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Tom Lane]

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers