Tom Lane wrote:
Don Y <[EMAIL PROTECTED]> 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...
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
