AssertArg failure in src/backend/executor/functions.c:check_sql_fn_retval()
Hi,
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);
TRAP: BadArgument("!(!((rettype) == 2283 || (rettype) == 2277 ||
(rettype) == 2776 || (rettype) == 3500 || (rettype) == 3831))", File:
"src/backend/executor/functions.c", Line: 1539)
Back-trace attached.
I've done a little bit of git-bisecting and this potential failure is
there since at least February 2012.
The comment above the function definition specifically says that "we
should never see a polymorphic pseudotype such as ANYELEMENT as rettype"
but given that a non-assert-enabled build seems to cope with such
pseudotypes well, I'm unsure the AssertArg is needed there at all.
Attachments:
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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