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