Tom Lane wrote:
> Don Y <pgsql@DakotaCom.Net> writes:
>> First, if the function is defined to return an INT16,
>> then returning a NULL doesn't make any sense -- since the
>> caller doesn't know how to deal with a NULL (it expects
>> an INT16, for example).
>
> Really? That would be a caller bug, if it's calling a function
> that might return NULL.
The function wouldn't be expected (nor defined!) to return NULL.
So, if it was INVOKED with a NULL, it could *detect* that
and issue an error message. But, it could NOT do PG_RETURN_NULL
since the caller(s) wouldn't be expecting a NULL return value
(why complicate every routine by forcing them all to handle
NULLs?). Hence my comment that I would have to pick some
generic (insignificant) value that was consistent with the
return type of the function and pass that along.
OTOH, if the function could *abort* it's invocation, then
I don't have to worry about return values. It is a closer
model to the STRICT behavior -- instead of aborting the
function invocation BEFORE (which STRICT essentially does),
I could abort it AFTER invocation (once I had detected
the NULL argument)
>> What I am trying to do is make functions more robust.
>> As it stands currently, the functions get written and
>> compiled "once". Thereafter, someone can FAIL to
>> specify STRICT when creating those functions in SQL
>> (CREATE FUNCTION...) and leave the server vulnerable
>> to having those functions invoked with NULL arguments.
>
> This would be the error of the person specifying the function's
> SQL definition. Since there are many ways to crash the system by
> writing a C function definition wrongly (eg, give the wrong
> datatypes), I can't get very excited about this particular one.
> We do make this a superuser-only feature for a reason: you're
> expected to be competent enough to get it right.
So, it might be more prudent to build the functions that
are needed and then just prevent other functions from being
added at all! That's a relatively easy parser hack...