Joe Conway <[EMAIL PROTECTED]> writes:So far so good. But look at this one: regression=# select dwarray(null,null); ERROR: cannot determine ANYARRAY/ANYELEMENT type because input is UNKNOWN
That seems correct to me. What would you expect to happen? There's no type we could assign as the function's actual return type.
I see your point, but mine was that in this case I'd like a NULL returned and I don't really care about the type. ISTM that NULL should be able to morph into any type it needs to.
This call makes it all the way to ExecEvalArray(), which means that dwarray() is getting evaluated even though it is declared STRICT and has been called with NULL inputs. That shouldn't happen, should it?
I think what is happening is that the SQL function is getting inlined, probably because the inlining logic thinks ARRAY[] is strict and so there'd be no change in semantics.
We could probably hack the inlining logic to prevent it from inlining the function in this scenario, but I wonder whether this doesn't say that ExecEvalArray is behaving inconsistently. In other operations, any NULL in means NULL out. Shouldn't it simply quietly return a NULL array if one of the supplied elements is NULL?
That probably makes good sense, at least until we can deal with NULL elements. Would that patch count as a bug fix?
Joe
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
