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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Piotr Stefaniak <postgres(at)piotr-stefaniak(dot)me>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: AssertArg failure in src/backend/executor/functions.c:check_sql_fn_retval()
Date: 2016-03-27 14:40:03
Message-ID: 4781.1459089603@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Piotr Stefaniak <postgres(at)piotr-stefaniak(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-03-27 15:52:18 Re: GinPageIs* don't actually return a boolean
Previous Message Tom Lane 2016-03-27 14:20:27 Re: Alter or rename enum value