Обсуждение: AssertArg failure in src/backend/executor/functions.c:check_sql_fn_retval()
AssertArg failure in src/backend/executor/functions.c:check_sql_fn_retval()
От
Piotr Stefaniak
Дата:
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.
Вложения
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
Re: 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.